2014-09-08 25 views
19

Poniższy kod C++ 11 kompiluje powodzeniem na moim GCC 4.8:C++ 11 prywatny konstruktor domyślny

struct NonStack 
{ 
private: 
    NonStack() = default; 
public: 
    static NonStack* Create(){ 
    return new NonStack; 
    } 
}; 
NonStack a; 

int main() { } 

Jednak dodaje daje błąd kompilacji:

struct NonStack 
{ 
private: 
    NonStack(){} 
}; 

NonStack a; 

int main() { } 

Dlaczego pierwszy jeden sukces? Czy prywatny konstruktor domyślnie nie powinien blokować tworzenia obiektu przez NonStack a;?

+2

Twój kod naprawdę robi [kompilacja] (http://coliru.stacked-crooked.com/a/55199811d96f1af7) na gcc4.8, ale 4.9 odrzuca go (tak jak powinien). – Praetorian

+8

To pytanie byłoby lepsze, gdyby było w nim pytanie. –

+0

Możesz także '= usunąć;' konstruktora. Powinien zachowywać się zgodnie z oczekiwaniami. – glampert

Odpowiedz

17

To jest błąd gcc 54812, kompilator nie respektuje specyfikacji dostępu dla jawnie domyślnych funkcji specjalnych. Bug 56429, który jest oznaczony jako duplikat wcześniejszego, ma przypadek testowy, który jest prawie identyczny z przykładem w pytaniu.

Rozwiązania należy zaktualizować do wersji gcc4.9, która rozwiązuje problem. Lub stwórz puste ciało dla konstruktora, zamiast jawnie je domyślnie, tak jak to zrobiliśmy w drugim przykładzie.

+3

Uwaga: ten błąd łączy się z [core language issue 1507] (http: //www.open- std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1507). To nie był błąd w GCC. Standard naprawdę użył powiedzieć, że ponieważ konstruktor był trywialny, konstruktor nie został wywołany, a jeśli konstruktor nie jest wywoływany, fakt, że jest "prywatny" nie jest problemem. – hvd

+0

@hvd Zgoda na to, że prywatny banalny konstruktor jest niedostępny, ale dobrze uformowany, był wadą standardu, ale raport o błędzie gcc nadal wskazuje błąd, ponieważ stosują tę logikę do niedostępnych, trywialnych destruktorów. Odpowiedź może być lepiej napisana, a ja zaktualizuję ją za chwilę. – Praetorian

+0

Ach tak, za tym tęskniłem, standard ma na dłużej odpowiednie brzmienie. Być może interesujące, standard wciąż nie wydaje się mieć zakazu "usuwania wskaźnika do niekompletnego typu klasy, który miałby niedopuszczalny trywialny destruktor, jest to tylko niezdefiniowane zachowanie, jeśli destruktor jest rzeczywiście nietrywialny. – hvd

Powiązane problemy