nested class inherits from nested class - c++

Question

I wanted the class C inherits from class A its virtual functions, and class D(nested class in class C) inherits from class B(nested class in class A) its data fields, here is what I have.
file1.h
class A{
public:
virtual void foo()=0;
class B{
public:
int data;
};
};
file2.h
class C : public A{
public:
class D : public A::B{
};
};
file2.cpp
void C::foo(){//code}
C::D::D():data(0){//Bad initialization list, error being data is not a member of C::D even it should inherits from its base class
data = 0; //good! compiler can see data is a member of A::B,and C::D inherits from it
}
I got two questions, first one is that is what I am doing the correct way to achieve this kind of inheritance. Secondly, as I commented, why compiler can see data is from A::B in the manual initialization process but not in the initialization list? Shouldn't them be in the same scope? Thank you very much
Edit1:
So if class C::D(foo) doesn't directly inherits from A::B(foo), but C inherits from A, my perception is that since C inherits from A and all its public fields, including its inner class A::B(foo), D(foo) has the exactly same name as A::B(foo) and is an inner class of C, like this, i.e used foo for both inner classes
class A{
public:
class foo{
public:
int data;
};
};
class C : public A{
public:
class foo{
};
};
Would it be confusing for the compiler when I call the C::foo directly? since there are two constructors with the name in the scope? or it chooses to call the "nearest" one, e.g C:foo? instead of climbing up the inheritance chain? Thank you very much

Answer 1

Yes, your approach is the correct way to achieve this kind of inheritance.
Initializer lists are there to control the arguments passed to the constructor. You can pass arguments to B's constructor, but not directly initialize a member of B (it's the job of its constructor). If there is no constructor specified for a base class or a member, the default constructor is used.
In your case, add a constructor to B to achieve what you want.
class A {
public:
class B{
public:
B(int i) : data(i) {}
int data;
};
};
class C : public A {
class D : public A::B {
};
};
C::D::D() :B(0) { }

Answer 2

From a syntactical point of view, it's correct(*1). Apart, of course, from the initialization list. You can only initialize current-class members (not base-class members) in the initializer list. That has nothing to do with the nesting.
class X
{
public:
int x;
};
class Y : X
{
Y() : x(0) {} //still illegal
};
I said syntactical POV because it's a weird thing to do... I'm sure there's a cleaner way to achieve what you actually want.

Answer 3

Your syntax for inheriting from a nested class is correct.
An initializer list is for initializing that class's members; base class members should be initialized in a base class constructor.

Answer 4

Syntactically, the accepted answer has answered your questions very well.
Here's my two cents on the design aspect related to the mechanism:
In your example abstract class A is essentially an interface. An interface should define behavior and behavior only. That being said, I don't think it makes sense to have a nested class in an interface.
1) an interface does not have any data member to be manipulated by the nested class, as is the case with your example. This eliminates the need for a nested class in the first place.
2) a nested class is not a behavior. So it shouldn't appear in an interface.
Now you may argue that your example is just a quick demonstration, and in reality you would have data members for the nested to manipulate, i.e. class A is not a pure interface. You simply want to provide a default implementation for the nested class B and let the class C decides how he wants to customize class B into his own class D. If that's the case I'm afraid the design is even worse.
3) Consider the iterator pattern. Class A is essentially an abstract container that can't be instantiated(because you have a pure virtual function in it) - let's map it to IContainer in our mind. Now you create a class C which has a vector/array implementation, with his own iterator D pointing to some element in the array.
Then you want create another class E which has a hash map implementation, with her own iterator F pointer to some pair in the hash map.
Here's the disaster: very often you cannot have a uniform interface across all the iterator classes(D, F ...) in the implementations of the containing classes(C, E ...) - very likely(consider the assignment operator: BIterator operator=(const BIterator& other);), class D has a function which accepts a class D object as argument: DIterator operator=(const DIterator& other); class F has some function that accepts a class F object as argument: FIterator operator=(const FIterator& other).
On the other hand, this wouldn't work because both DIterator and FIterator are sub-classes of BIterator - You can't override a function with 'narrower'(or 'more specific') arguments as it violates the contravariance of argument types(C++ does not allow contravariant arguments, so it requires matching argument types; so technically you can have FIterator operator=(const BIterator& other) for class F and do a run-time dynamic cast from BIterator to FIterator - but that's ugly and it doesn't make sense: a concrete apple has an assignment operator that assigns an abstract 'fruit' to itself). You just got yourself in a dilemma.
To sum up, due to reasons 1) 2) and 3), don't include a nested class in an interface/abstract base class. The iterator pattern is just an example, there could be numerous occasions on which you shoot yourself in the feet as long as the nested classes interact with the containing classes. If not, then there's no point in having nested classes in the first place.