Pros and cons of using nested C++ classes and enumerations?

by

Nested classes

There are several side effects to classes nested inside classes that I usually consider flaws (if not pure antipatterns).

Let’s imagine the following code :

class A
{
   public :
      class B { /* etc. */ } ;

   // etc.
} ;

Or even:

class A
{
   public :
      class B ;

   // etc.
} ;

class A::B
{
   public :

   // etc.
} ;

So:

  • Privilegied Access: A::B has privilegied access to all members of A (methods, variables, symbols, etc.), which weakens encapsulation
  • A’s scope is candidate for symbol lookup: code from inside B will see all symbols from A as possible candidates for a symbol lookup, which can confuse the code
  • forward-declaration: There is no way to forward-declare A::B without giving a full declaration of A
  • Extensibility: It is impossible to add another class A::C unless you are owner of A
  • Code verbosity: putting classes into classes only makes headers larger. You can still separate this into multiple declarations, but there’s no way to use namespace-like aliases, imports or usings.

As a conclusion, unless exceptions (e.g. the nested class is an intimate part of the nesting class… And even then…), I see no point in nested classes in normal code, as the flaws outweights by magnitudes the perceived advantages.

Furthermore, it smells as a clumsy attempt to simulate namespacing without using C++ namespaces.

On the pro-side, you isolate this code, and if private, make it unusable but from the “outside” class…

Nested enums

Pros: Everything.

Con: Nothing.

The fact is enum items will pollute the global scope:

// collision
enum Value { empty = 7, undefined, defined } ;
enum Glass { empty = 42, half, full } ;

// empty is from Value or Glass?

Ony by putting each enum in a different namespace/class will enable you to avoid this collision:

namespace Value { enum type { empty = 7, undefined, defined } ; }
namespace Glass { enum type { empty = 42, half, full } ; }

// Value::type e = Value::empty ;
// Glass::type f = Glass::empty ;

Note that C++0x defined the class enum:

enum class Value { empty, undefined, defined } ;
enum class Glass { empty, half, full } ;

// Value e = Value::empty ;
// Glass f = Glass::empty ;

exactly for this kind of problems.

More Related Contents:

  1. Why is enum class preferred over plain enum?
  2. Forward declaration of nested types/classes in C++
  3. namespaces for enum types – best practices
  4. Is it possible to pass a class as an argument of a function in C++
  5. Title Name not showing and background color not changing
  6. Compiler Crash with C++ Array
  7. Is it possible to force c++ class instantiation on the heap?
  8. What are access specifiers? Should I inherit with private, protected or public?
  9. C++: What is the size of an object of an empty class?
  10. Splitting templated C++ classes into .hpp/.cpp files–is it possible?
  11. Separating class code into a header and cpp file
  12. What is the ‘this’ pointer?
  13. Base enum class inheritance
  14. How to copy/create derived class instance from a pointer to a polymorphic base class?
  15. Is passing a C++ object into its own constructor legal?
  16. Allow for Range-Based For with enum classes?
  17. Do class functions/variables have to be declared before being used?
  18. What is the difference between a concrete class and an abstract class?
  19. Extending enums in C++?
  20. C++ N nested vectors at runtime
  21. Semicolon after class declaration braces
  22. Difference between Enum and Define Statements
  23. How to add constructors/destructors to an unnamed class?
  24. Class template with template class friend, what’s really going on here?
  25. Detect when multiple enum items map to same value
  26. Different ways of initializing an object in c++
  27. Wrapping C++ class API for C consumption
  28. Class inherited from class without default constructor
  29. Template type deduction in C++ for Class vs Function?
  30. Same class name in different C++ files

Leave a Comment