Why are two using clauses resolving to the same type seen as ambigious in gcc

Question

I have two base classes with using clauses

 class MultiCmdQueueCallback {
  using NetworkPacket  = Networking::NetworkPacket;
  ....
 }


 class PlcMsgFactoryImplCallback {
   using NetworkPacket = Networking::NetworkPacket;
  ....
 }

I then declare a class

class PlcNetwork : 
  public RouterCallback, 
  public PlcMsgFactoryImplCallback, 
  public MultiCmdQueueCallback {
  private:
    void sendNetworkPacket(const NetworkPacket &pdu);
}

the compiler then flags an error reference to 'NetworkPacket' is ambiguous 'sendNetworkPacket(NetworkPacket &... '

Now both 'using clauses' resolve to the same underlying class Networking:NetworkPacket

and in fact if I replace the method declaration with:

 void sendNetworkPacket(const Networking::NetworkPacket &pdu);

it compiles fine.

Why is the compiler treating each using clause as a distinct type even though they both point to the same underlying type. Is this mandated by the standard or do we have a compiler bug ?

Answer 1

Before looking at alias resulting type, (and accessibility)

we look at names

and indeed,

NetworkPacket might be

• MultiCmdQueueCallback::NetworkPacket
• or PlcMsgFactoryImplCallback::NetworkPacket

The fact they both point to Networking::NetworkPacket is irrelevant.

We do first name resolution, which results in ambiguity.

Answer 2

You simply can resolve the ambiguity by manually selecting which one you want to use.

class PlcNetwork : 
  public RouterCallback, 
  public PlcMsgFactoryImplCallback, 
  public MultiCmdQueueCallback {

using NetworkPacket= PlcMsgFactoryImplCallback::NetworkPacket; // <<< add this line
private:
    void sendNetworkPacket(const NetworkPacket &pdu);

}

The compiler only looks for the definitions in the base classes. If the same type and or alias is present in both base classes it simply complains that it does not know which one to use. It doesn't matter if the resulting type is the same or not.

The compiler only looks for names in the first step, fully independent if this name is a function, type, alias, method or whatever. If names are ambiguous no further action is done from the compiler! It simply complains with the error message and stops. So simply resolve the ambiguity with the given using statement.

Answer 3

From the docs:

A type alias declaration introduces a name which can be used as a synonym for the type denoted by type-id. It does not introduce a new type and it cannot change the meaning of an existing type name.

Although, those two using clauses represent the same type, compiler has two choices in the following situation:

void sendNetworkPacket(const NetworkPacket &pdu);

It can choose between:

• MultiCmdQueueCallback::NetworkPacket and
• PlcMsgFactoryImplCallback::NetworkPacket

because it inherits from both MultiCmdQueueCallback and PlcMsgFactoryImplCallback base classes. A result of compiler's name resolution is ambiguity error that you have. In order to fix this, you need to explicitly instruct the compiler to use one or another like this:

void sendNetworkPacket(const MultiCmdQueueCallback::NetworkPacket &pdu);

or

void sendNetworkPacket(const PlcMsgFactoryImplCallback::NetworkPacket &pdu);

Answer 4

There are two errors:

1. Accessing private type aliases
2. Ambiguous reference to type aliases

private-private

I don't see a problem that compiler complains about the second problem first because the order doesn't really matter - you have to fix both issues to proceed.

public-public

If you change the visibility of both MultiCmdQueueCallback::NetworkPacket and PlcMsgFactoryImplCallback::NetworkPacket to either public or protected, then the second issue (ambiguity) is obvious - those are two different type aliases although they have the same underlying data type. Some may think that a "clever" compiler can solve this (a specific case) for you, but keep in mind that the compiler needs to "think in general" and make decisions based on global rules instead of making case-specific exceptions. Imagine the following case:

class MultiCmdQueueCallback {
    using NetworkPacketID  = size_t;
    // ...
};


class PlcMsgFactoryImplCallback {
    using NetworkPacketID = uint64_t;
    // ...
};

Should the compiler treat both NetworkPacketID the same? Sure not. Because on a 32-bit system, size_t is 32-bit long while uint64_t is always 64-bit. But if we want the compiler to check for underlying data types, then it couldn't distinguish those on a 64-bit system.

public-private

I believe this example doesn't make any sense in OP's use-case, but since here we are solving problems in general, let's consider that:

class MultiCmdQueueCallback {
private:
    using NetworkPacket  = Networking::NetworkPacket;
    // ...
};

class PlcMsgFactoryImplCallback {
public:
    using NetworkPacket  = Networking::NetworkPacket;
    // ...
};

I think in this case the compiler should treat PlcNetwork::NetworkPacket as PlcMsgFactoryImplCallback::NetworkPacket because it has no other choises. Why it still refuses to do so and blames on ambiguity is a mistery to me.