One piece does not result in ambiguity, but the other does. What is the difference?

Question

While working on providing reflection information about the base classes of user-defined classes, I stumbled upon a problem with ambiguous path to a base class. However, I do not understand when exactly that problem appears. Here are two pieces of code that seem to possess the ambiguity. However, only the second piece does not compile. The question is: what is the difference between the two pieces?

The following code compiles:

template <class Base1_ = void, class Base2_ = void, class Base3_ = void,
          class Base4_ = void>
struct ManagedNode;

// For classes that do not derive
template <> struct ManagedNode<void, void, void, void> {
    using Base1 = void; using Base2 = void; using Base3 = void;
    using Base4 = void;
};

// For classes that derive from two base classes
template <class Base1_, class Base2_>
struct ManagedNode<Base1_, Base2_, void, void> : public Base1_, public Base2_ {
    using Base2 = Base2_; // Base1 isn't needed in the real design,
                          // but that doesn't compile (see below)
};

// Some user classes for testing the concept

struct A : public ManagedNode<> {};

struct B : public ManagedNode<> {};

struct C : public ManagedNode<A, B> {}; // No ambiguity, although C
                                        // derives from ManagedNode<>
                                        // through both A and B.

If we add the following (which is the real way I would like to do things, since it allows to avoid duplication of code), the code does not compile:

// For classes that derive from a single base class
template <class Base1_>
struct ManagedNode<Base1_, void, void, void> : public ManagedNode<>,
                                               public Base1_ {
    using Base1 = Base1_;
};

struct D: public ManagedNode<A> {}; // error: direct base 
                                    // ‘ManagedNode<void, void, void, void>’ 
                                    // inaccessible in ‘ManagedNode<A>’ 
                                    // due to ambiguity

EDIT: Please note that, in the two-parameter case, I derive both from A and from B, both of which derive from ManagedNode<>. So, why isn't there ambiguity in that case as well as in the one-parameter case?

Tip: you can just write `template struct ManagedNode : Args...` and avoid saying things like `4` in your code. — Kerrek SB, Dec 13 '15 at 20:41
@KerrekSB Do you mean without a need for specializations? But then how do I provide a `using` declarations for each template argument? — AlwaysLearning, Dec 13 '15 at 20:44
I mean just as a different, cleaner and more systematic approach. You could have a member type `T = std::tuple` and users could use `std::tuple_element` to get at each member type of the pack. — Kerrek SB, Dec 13 '15 at 20:45
[This thread](http://stackoverflow.com/q/4118412/3953764) answers your question — Piotr Skotnicki, Dec 13 '15 at 20:47
@PiotrSkotnicki Do you mean that `C` has two ManagedNode<> sub-objects? By why would that be the case in one case and not the other? — AlwaysLearning, Dec 13 '15 at 21:08
@AlwaysLearning no, it's because you can never cast `ManagedNode` to its direct base class `ManagedNode<>`, though, you can cast it to its indirect base class `ManagedNode<>` through `A` — Piotr Skotnicki, Dec 13 '15 at 21:22
@PiotrSkotnicki Got you! I would very much appreciate if you look at the solution for the reflection problem that I came up with thanks to your explanation (http://stackoverflow.com/a/34256791/2725810) and see if you have a suggestion for the resulting problem. — AlwaysLearning, Dec 13 '15 at 21:57

One piece does not result in ambiguity, but the other does. What is the difference?

0 Answers0

Linked