Ambiguos constructor call

DocShoe

Hi zusammen,

ich habe hier dieses Konstrukt:

class SomeInterface
{
public:
   SomeInterface()
   {
   }
   virtual ~SomeInterface()
   {
   }
};

class Base
{
   SomeInterface& Ref_;
public:
   explicit Base( SomeInterface& ref ) :
      Ref_( ref )
   {
   }

   Base( Base const& other ) = delete;
 
   virtual ~Base()
   {
   }
};

class Derived : public Base, public SomeInterface
{
public:
   Derived() :
      Base( *this )
   {
   }
};

int main() 
{
   Derived d;
   return 0;
}

Der Compiler beschwert sich inZeile 37 darüber, dass der Konstruktoraufruf in Zeile 32 mehrdeutig ist (zwischen gelöschtem Kopierkonstruktor Base::Base( Base const& other ) und Base::Base( SomeInterface& interface ).
Warum zieht der Compiler den explizit gelöschten Kopierkonstruktor in Betracht und benutzt nicht den einzigen Base-Konstruktor?

Edit:
Zeilennummer korrigiert

Th69

Du meinst Zeile 32 (ehemals 33 vor deinem Edit, argh)?

Erst dachte ich , daß explicit daran Schuld ist, aber ein Entfernen hat nicht geholfen, nur ein expliziter(!) Cast:

Base( static_cast<SomeInterface&>(*this) )

Hier noch ein SO-Link mit Auszügen aus dem C++ Standard dazu: Deleting overloaded function. C++11. Call of overloaded ... is ambiguous

PS:

Der Compiler beschwert sich in Zeile 37 darüber, dass der Konstruktoraufruf in Zeile 32 mehrdeutig ist...

LOL

DocShoe

@Th69
Ja, genau. Mit dem static cast wird´s übersetzt, aber ich würde schon gern wissen, warum der Compiler den gelöschten Kopierkonstruktor nicht ignoriert und den einzig verfügbaren Konstruktor für Base benutzt.

PS:
Soll ich nochmal?

Th69

s. "§13.3.3.1 Implicit conversion sequences" in dem SO-Link.

wob

@DocShoe sagte in Ambiguos constructor call:

Warum zieht der Compiler den explizit gelöschten Kopierkonstruktor in Betracht und benutzt nicht den einzigen Base-Konstruktor?

Weil erst geguckt wird, welche Funktionen passen und erst nach der Auswahl der passenden Funktion geschaut wird, ob wir sie auch aufrufen dürfen (z.B. ob sie private ist). Das hat den praktischen Vorteil, dass nicht "zufällig" irgendeine andere Funktion aufgerufen wird, nur weil du die Sichtbarkeit einer Funktion geändert hast.