What is advantage of implementing inner classes as seperate classes with name space in C++?

Question

1. What is advantage of implementing inner classes as separate classes with name space in C++?
2. Will there be any added advantage with Approach-1?

3. Pros & Cons with both approaches?

   Approach-1: using namespace

MyInnerClass.h

namespace inner{
class MyInnerClass
{
    public:
    MyInnerClass();
    virtual ~MyInnerClass();
};

};

MyInnerClass.cpp

#include "MyInnerClass.h"
namespace inner
{

MyInnerClass::MyInnerClass()
{
}

MyInnerClass::~MyInnerClass()
{
}

}

MyOuterClass.h

#include "MyInnerClass.h"

namespace inner{
    class MyInnerClass;
};

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

    private:
        inner::MyInnerClass* ptrMyInnerClass;
};

MyOuterClass.cpp

#include "MyOuterClass.h"

MyOuterClass::MyOuterClass()
{
    ptrMyInnerClass= new inner::MyInnerClass();
}

MyOuterClass::~MyOuterClass()
{
}

Approach-2: implementing as real inner classes

class MyOuterClass
{
/*  Inner Class */
    public:
        class MyInnerClass
        {
            public:
                MyInnerClass() {}
                virtual ~MyInnerClass() {}
        };

    public:
        MyOuterClass();
        virtual ~MyOuterClass();

    private:
        MyInnerClass* ptrMyInnerClass;
};

Answer 1

In larger projects, otherwise will be handicapped, similar objects or classes are categorized into corresponding namespaces for ease of refactoring and readability.

Normally, an object which will be intrinsic to another object only and rarely going to be used otherwise is declared as private inner class. By doing so, the intent is made clearer as the implementation is hidden and the inner object is not exposed.

Answer 2

I only know one advantage of the namespace scheme. With namespaces, you can forward declare classes, while you cannot do the same with inner classes, if the outer class definition is not available. So, with namespaces, you can do this:

namespace Outer {
class Inner;
}

However, you cannot do the same with inner classes, if definition of Outer is not available:

class Outer; // we forward declare Outer
class Outer::Inner; // this doesn't compile

In the same manner, you cannot define Outer::Inner without the definition of Outer.

Because of this I almost never use inner classes (I only use small inner class, when I'm 100% sure the forward declaration is not needed, which is usually the case when the inner class is not public).

Note, there is a 3rd solution, which I usually use: I name "inner" class as something like OuterInner.

For example, if you have an outer class named SomeManager, and you would have a public inner class named Node, I'd use class SomeManagerNode:

class SomeManager;
class SomeManagerNode;

The only difference I know about this method is that SomeManagerNode cannot access non-public members of SomeManager (If Node was an inner class to SomeManager, it could access all members of it). But this can be desirable in certain situations, so it is not a real drawback. But if the access is needed, you can declare SomeManagerNode as a friend of SomeManager.

The only reason to use inner classes is when the inner class is a private implementation detail, which is not used anywhere outside the class.