Warum ist meine Klasse nicht standardmäßig konstruierbar?

Ich habe diese Klassen:

#include <type_traits>

template <typename T>
class A {
public:
    static_assert(std::is_default_constructible_v<T>);

};

struct B {
   struct C {
      int i = 0;
   };

    A<C> a_m;
};

int main() {
    A<B::C> a;
}

Ist beim Kompilieren a_mnicht standardmäßig konstruierbar, aist es aber .

Beim Wechsel Czu:

struct C {
      int i;
   };

alles ist gut.

Getestet mit Clang 9.0.0.

Dies wird sowohl durch den Text des Standards als auch durch mehrere wichtige Implementierungen, wie in den Kommentaren angegeben, nicht zugelassen, jedoch aus völlig unabhängigen Gründen.

Erstens der Grund "nach dem Buch": Der Punkt der Instanziierung von A<C>liegt nach dem Standard unmittelbar vor der Definition vonB und der Punkt der Instanziierung von std::is_default_constructible<C>liegt unmittelbar davor:

Für eine Klassenvorlagenspezialisierung [...], wenn die Spezialisierung implizit instanziiert wird, weil sie aus einer anderen Vorlagenspezialisierung heraus referenziert wird, wenn der Kontext, aus dem auf die Spezialisierung verwiesen wird, von einem Vorlagenparameter abhängt und wenn die Spezialisierung nicht zuvor instanziiert wurde Für die Instanziierung der einschließenden Vorlage liegt der Instanziierungspunkt unmittelbar vor dem Instanziierungspunkt der einschließenden Vorlage. Andernfalls steht der Instanziierungspunkt für eine solche Spezialisierung unmittelbar vor der Namespace-Bereichsdeklaration oder -definition, die sich auf die Spezialisierung bezieht.

Da Cdies zu diesem Zeitpunkt eindeutig unvollständig ist, ist das Verhalten der Instanziierung std::is_default_constructible<C>undefiniert. Siehe jedoch Kernproblem 287 , das diese Regel ändern würde.

In Wirklichkeit hat dies mit dem NSDMI zu tun.

• NSDMIs sind seltsam, weil sie verzögert analysiert werden - oder im Standard-Sprachgebrauch sind sie ein "Kontext der vollständigen Klasse".
• Dies = 0könnte sich also im Prinzip auf Dinge beziehen, die Bnoch nicht deklariert sind, sodass die Implementierung nicht wirklich versuchen kann, sie zu analysieren, bis sie fertig ist B.
• Das Abschließen einer Klasse erfordert die implizite Deklaration spezieller Elementfunktionen, insbesondere des Standardkonstruktors, da Ckein Konstruktor deklariert ist.
• Teile dieser Erklärung (Konstanz, Nichtausnahme) hängen von den Eigenschaften des NSDMI ab.
• Wenn der Compiler das NSDMI nicht analysieren kann, kann er die Klasse nicht vervollständigen.
• Infolgedessen hält es zu dem Zeitpunkt, an dem es instanziiert wird A<C>, dies für Cunvollständig.

Dieser gesamte Bereich, der sich mit Regionen mit verzögerter Analyse befasst, ist stark unterbestimmt, mit der damit einhergehenden Divergenz bei der Umsetzung. Es kann eine Weile dauern, bis es aufgeräumt wird.

Undefiniertes Verhalten ist es:

Wenn eine Instanziierung einer obigen Vorlage direkt oder indirekt von einem unvollständigen Typ abhängt und diese Instanziierung zu einem anderen Ergebnis führen könnte, wenn dieser Typ hypothetisch abgeschlossen wäre, ist das Verhalten undefiniert.