std :: is_default_constructibleT Fehler, wenn der Konstruktor privat ist

8

Ich habe folgendes Snippet

%Vor%

Die Bedingungen sind nicht gleich, aber die erste Bedingung funktioniert gut und die zweite Konstruktion gibt einen Fehler, dieser Konstruktor ist privat. Compiler gcc 4.7 ... Also, ist das GCC Bug, oder es ist durch Standard definiert?

Ссылка 5 $

OK. Da diese Bedingungen wirklich ungleich sind - wir können so etwas verwenden.

%Vor%

Ссылка 24 $

Wie auch immer, ich weiß, dass static_assert nicht fehlschlagen sollte, da Typen wirklich nicht standardmäßig konstruierbar / nicht nicht konstruierbar sind. Frage ist: WARUM gibt es Kompilierungsfehler, nicht durch meine statische Behauptung?

    
ForEveR 25.12.2012, 11:07
quelle

1 Antwort

5

Sieht nach einem Compilerfehler aus. Sehen wir uns das folgende Beispiel von SFINAE an (ähnliche Implementierung wird in g++ 's type_traits header) verwendet

%Vor%

Die zweite Assert funktioniert wie erwartet, wir können Delete type nicht ableiten, da die Klasse nur einen gelöschten Konstruktor hat. Wenn der Compiler versucht, den Typ von Private() abzuleiten, wird der Fehler: Private::Private() is private angezeigt. Also, wir haben zwei Klassen mit privaten Konstruktor, aber einer von ihnen gibt Fehler, und zweitens nicht. Ich denke, dass dieses Verhalten falsch ist, aber ich kann keine Bestätigung im Standard finden.

P.S. Alle off präsentierten Codes werden ohne Fehler kompiliert.

    
soon 25.12.2012, 15:27
quelle

Tags und Links