C++ Nested Classes: Advantages & Disadvantages

[Potential]

C++ -- Nested Classes

A post or two I have been working with appeared to be associated with students in a C computer language programming course. In other words, the class may have not been object oriented. Also, mentioned in one post was the concept of housekeeping being less important than the actual logic of producing correct results, at least in a Computer Science class. I would like to address both of these issues from a standpoint of who the type of person I would hire. I am surprised C is being taught instead of C++ and that housekeeping is considered less important that the ultimate result producing logic.

If I were hiring right now, I would want the type of programmer that knows C++ object oriented programming. Once I find these types of people, I then look at their housekeeping habits, such as not having memory leaks, always initializing every variable or object, and always checking NULL pointers prior to being used. If a potential prgrammer has these abilities, they are considered for the job and if they don't, the resume goes on the 'other' stack.

Now on to a an open discussion of object oriented programming, which in my opinion should be taught. Here is an example:


Over the years, I have used nested classes and non-nested classes in an actual production environment. I have found advantages and disavantages in using both concepts.

Using non-nested inheritance...

class Force
{
public:
    Force();
    virtual ~Force();

protected:

};

class NuclearForce : public Force
{
public:
    NuclearForce();
    virtual ~NuclearForce();

protected:

};

class ElectronForce : public Force
{
public:
    ElectronForce();
    virtual ~ElectronForce();

protected:
 
};

Using nested without inheritance...

class Force
{
public:
    Force();
    virtual ~Force();

    class NuclearForce
    {
    public:
        NuclearForce ();
        virtual ~NuclearForce();

    protected:

    };

    class ElectronForce
    {
    public:
        ElectronForce();
        virtual ~ElectronForce();

    protected:
 
    };

protected:
};

I would really enjoy reading all comments and discussing object oriented technologies.

 

[Coin]

I think most classes these days that intend to teach object oriented programming will just jump straight to something like Java... the problem with C++ from a teaching perspective is that it as a language is structured in a way that makes it difficult to adequately teach its object oriented elements until the student fully understands the C underpinnings. And teaching the C underpinnings can take an entire course's worth of time unto itself... So even when C++ is being taught instead of C, these C++ classes will often just be teaching vanilla C (except with cin/cout added) for a long time and then introduce object oriented programming quickly at the end.

As for your second thing, it seems like nested and descendant classes would be likely to be used only for fairly different purposes. Aren't nested classes in C++ basically just using the enclosing class like a namespace?

 

[Potential]

There is much more of a difference in nested classes relative to non-nested classes than what meets the eye. The naming convention, or the namespace, of course changes and how one accesses objects changes. However, imagine the potential difference in performance as I hope to convey.



In my experience, nested classes can offer a huge advantage in performance and robustness during runtime except when a program is loading data during load time or saving during save time, and mapping the data to or from the nested slots. In these exceptions, the additional overhead is minimal.

For example, say I am loading a huge Oracle database job with 100 tabular tables and I am holding the associated data in RAM in class data structures. In my view, there are two ways I can implement this which are described in my first post...nested and non-nested. The way I think of this is the nested concept is object oriented and the non-nested concept is tabular although both can have common object oriented features. I realize this will be a little abstract, so bear with me.

Generally, when designing the class data structures, I want to share as many classes as possible. To implement this, I look for common denominators in groups of data. The classes that are unique do not have to be exposed but the shares ones do, so I wish to minimize class exposure wherever possible. If I create once class for each database table, then I have 100 classes plus the shared data classes. All visually capable interface and other supported classes are kept separate for obvious reasons.

In this non-nested case, or what I call the "outside in" method, in order to access one of the 100 objects, or tables, I might have to touch each 100 of the classes and then potentially cycle for specific data from there, such as embedded arrays, etc., EACH time I needed any data unless the active thread, by chance, was inside an object. This could result in exponentially more loops and hence more time, depending on what data I needed.

In the nested case, or what I call "inside out", the quantity of loops can be drastically limited if I transfer the 100 tabular table data into the object oriented design classes when loaded from the database. There is a little overhead during this step but the increased performance is eye-popping drastic later on. Once I am in one of the 100 objects, I usually never have to access another object from outside because all the data I need in already nested inside each and every time.

Make sense?

If the program runs a lengthy time to perform one complex operation, the savings can be significant. Time is money right?

 

[Potential]

In my original post, you may have noticed I mentioned non-nested inheritance and nested inheritance and the two primary concepts I presented. We can take the nested non-inheritance concept one notch further, to test the limits of a more scalable system. Here, I present an example of nested inheritance. The difference between the two, may not look like much but there is a world of difference. Not only do I get access to improved performance as mentioned in my prior post, and all the other inherent capabilities of C++, like code reuse of objects, but I may get the ability to hook into it with future program versioning.

class Synapse
{
public:
    Synapse();
    virtual Synapse();

     class Force
     {
     public:
         Force();
         virtual ~Force();
     };

     class NuclearForce : public Force
     {
     public:
         NuclearForce ();
         virtual ~NuclearForce();

     protected:

     };

     class ElectronForce : public Force
     {
     public:
         ElectronForce();
         virtual ~ElectronForce();

     protected:
 
     };

protected:

};

Scalable Extensibility via Nested Inheritance
(Technical Report)
Nathaniel Nystrom Stephen Chong Andrew C. Myers
Computer Science Department
Cornell University
{nystrom,schong,andru}@cs.cornell.edu

Abstract

Inheritance is a useful mechanism for factoring and reusing
code. However, it has limitations for building extensible systems.
We describe nested inheritance, a mechanism that addresses
some of the limitations of ordinary inheritance and
other code reuse mechanisms. Using our experience with
an extensible compiler framework, we show how nested inheritance
can be used to construct highly extensible software
frameworks. The essential aspects of nested inheritance are
formalized in a simple object-oriented language with an operational
semantics and type system. The type system of this
language is sound, so no run-time type checking is required
to implement it and no run-time type errors can occur. We
describe our implementation of nested inheritance as an unobtrusive
extension of the Java language, called Jx. Our prototype
implementation translates Jx code to ordinary Java code,
without duplicating inherited code.


8 Conclusions

Nested inheritance is an expressive yet unobtrusive mechanism
for writing highly extensible frameworks. It provides the
ability to inherit a collection of related classes while preserving
the relationships among those classes, and it does so without
sacrificing type safety or imposing new run-time checks.
The use of dependent classes and prefix types enables reusable
code to unambiguously yet flexibly refer to components on
which it depends. Nested inheritance is fundamentally an inheritance
mechanism rather than a parameterization mechanism,
which means that every name introduced by a component
becomes a possible implicit hook for future extension.
Therefore extensible code does not need to be burdened by explicit
parameters that attempt to capture all the ways in which
it might be extended later.

We formalized the essential aspects of nested inheritance
in an object calculus with an operational semantics and type
system, and were able to show that this type system is sound.
Thus extensibility is obtained without sacrificing compile-time
type safety.

http://www.cs.cornell.edu/andru/papers/ncm04-tr.pdf