Mam dwie klasy podstawowe z wykorzystaniem klauzul

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


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

Następnie deklaruję klasę

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

kompilator następnie oznacza odniesienie błędu do „NetworkPacket” jest niejednoznaczne „sendNetworkPacket (NetworkPacket i ...”

Teraz obie „klauzule używające” rozwiązują tę samą klasę bazową Networking: NetworkPacket

i w rzeczywistości, jeśli zastąpię deklarację metody:

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

dobrze się kompiluje.

Dlaczego kompilator traktuje każdą klauzulę używającą jako odrębny typ, mimo że oba wskazują na ten sam typ bazowy. Czy jest to wymagane przez standard, czy mamy błąd kompilatora?

Przed spojrzeniem na typ wynikowy aliasu (i dostępność)

patrzymy na imiona

i rzeczywiście

NetworkPacket może być

• MultiCmdQueueCallback::NetworkPacket
• lub PlcMsgFactoryImplCallback::NetworkPacket

Fakt, na który oba wskazują, Networking::NetworkPacketjest nieistotny.

Robimy rozpoznawanie imienia, co powoduje niejasności.

Możesz po prostu rozwiązać dwuznaczność, ręcznie wybierając, którego chcesz użyć.

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

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

}

Kompilator szuka tylko definicji w klasach podstawowych. Jeśli ten sam typ i / lub alias jest obecny w obu klasach podstawowych, po prostu narzeka, że ​​nie wie, którego użyć. Nie ma znaczenia, czy wynikowy typ jest taki sam, czy nie.

Kompilator szuka nazw tylko w pierwszym kroku, w pełni niezależny, jeśli jest to funkcja, typ, alias, metoda lub cokolwiek innego. Jeśli nazwy są niejednoznaczne, kompilator nie wykonuje żadnych dalszych działań! Po prostu narzeka na komunikat o błędzie i zatrzymuje się. Po prostu usuń niejednoznaczność z podaną instrukcją using.

Z dokumentów :

Deklaracja aliasu typu wprowadza nazwę, która może być używana jako synonim typu oznaczonego przez typ-id. Nie wprowadza nowego typu i nie może zmienić znaczenia istniejącej nazwy typu.

Chociaż te dwie usingklauzule reprezentują ten sam typ, kompilator ma dwie możliwości w następującej sytuacji:

void sendNetworkPacket(const NetworkPacket &pdu);

Może wybierać między:

• MultiCmdQueueCallback::NetworkPacket i
• PlcMsgFactoryImplCallback::NetworkPacket

ponieważ dziedziczy z obu MultiCmdQueueCallbacki PlcMsgFactoryImplCallbackbazowych klas. Rezultatem rozpoznawania nazw kompilatora jest błąd niejednoznaczności. Aby to naprawić, musisz wyraźnie poinstruować kompilator, aby używał jednego lub drugiego w ten sposób:

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

lub

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

Istnieją dwa błędy:

1. Dostęp do aliasów typu prywatnego
2. Niejednoznaczne odniesienie do aliasów typów

prywatny-prywatny

Nie widzę problemu, że kompilator narzeka najpierw na drugi problem, ponieważ kolejność nie ma tak naprawdę znaczenia - musisz rozwiązać oba problemy, aby kontynuować.

publiczny-publiczny

Jeśli zmienisz widoczność zarówno MultiCmdQueueCallback::NetworkPacketi PlcMsgFactoryImplCallback::NetworkPacketna publicznym lub chronionym, potem drugi emisyjnej (dwuznaczności) jest oczywista - to są dwie różne aliasy typu choć mają ten sam podstawowy typ danych. Niektórzy mogą myśleć, że „sprytny” kompilator może rozwiązać ten problem (konkretny przypadek), ale należy pamiętać, że kompilator musi „myśleć ogólnie” i podejmować decyzje w oparciu o reguły globalne zamiast robić wyjątki dla poszczególnych przypadków. Wyobraź sobie następujący przypadek:

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


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

Czy kompilator powinien traktować NetworkPacketIDto samo? Na pewno nie. Ponieważ w systemie 32-bitowym size_tjest on 32-bitowy, a uint64_tzawsze jest 64-bitowy. Ale jeśli chcemy, aby kompilator sprawdzał podstawowe typy danych, nie mógł rozróżnić tych w systemie 64-bitowym.

publiczny prywatny

Uważam, że ten przykład nie ma sensu w przypadku użycia OP, ale ponieważ tutaj rozwiązujemy problemy w ogóle, rozważmy:

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

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

Myślę, że w tym przypadku kompilator powinien traktować PlcNetwork::NetworkPackettak, PlcMsgFactoryImplCallback::NetworkPacketponieważ nie ma innych wyborów. Dlaczego nadal tego nie robi i obwinianie się o dwuznaczność jest dla mnie tajemnicą.