Was sind all die allgemeinen undefinierten Verhaltensweisen, die ein C++-Programmierer kennen sollte? [closed]

Was sind all die allgemeinen undefinierten Verhaltensweisen, die ein C++-Programmierer kennen sollte?

Sagen Sie, wie:

a[i] = i++;

Zeiger

• Dereferenzierung a NULL Zeiger
• Dereferenzieren eines Zeigers, der von einer “neuen” Zuordnung der Größe Null zurückgegeben wird
• Verwenden von Zeigern auf Objekte, deren Lebensdauer abgelaufen ist (z. B. Stapeln von zugewiesenen Objekten oder gelöschten Objekten)
• Dereferenzieren eines noch nicht definitiv initialisierten Zeigers
• Durchführen einer Zeigerarithmetik, die ein Ergebnis außerhalb der Grenzen (entweder über oder unter) eines Arrays liefert.
• Dereferenzieren des Zeigers an einer Stelle hinter dem Ende eines Arrays.
• Konvertieren von Zeigern auf Objekte inkompatibler Typen
• Verwenden memcpy um überlappende Puffer zu kopieren.

Puffer läuft über

• Lesen oder Schreiben in ein Objekt oder Array mit einem negativen Offset oder jenseits der Größe dieses Objekts (Stapel-/Heap-Überlauf)

Ganzzahlüberläufe

• Vorzeichenbehafteter Integer-Überlauf
• Auswerten eines Ausdrucks, der nicht mathematisch definiert ist
• Linksverschiebung von Werten um einen negativen Betrag (Rechtsverschiebungen um negative Beträge sind implementierungsdefiniert)
• Das Verschieben von Werten um einen Betrag, der größer oder gleich der Anzahl der Bits in der Zahl ist (z int64_t i = 1; i <<= 72 ist nicht definiert)

Typen, Cast und Const

• Umwandeln eines numerischen Werts in einen Wert, der nicht durch den Zieltyp dargestellt werden kann (entweder direkt oder über static_cast)
• Verwenden einer automatischen Variablen, bevor sie definitiv zugewiesen wurde (z. B. int i; i++; cout << i;)
• Verwenden des Werts eines beliebigen Objekts vom Typ außer volatile oder sig_atomic_t beim Empfang eines Signals
• Versuch, ein Zeichenfolgenliteral oder ein anderes konstantes Objekt während seiner Lebensdauer zu ändern
• Verketten eines schmalen mit einem breiten Zeichenfolgenliteral während der Vorverarbeitung

Funktion und Vorlage

• Keinen Wert von einer Wert zurückgebenden Funktion zurückgeben (direkt oder durch Abfließen von einem try-Block)
• Mehrere unterschiedliche Definitionen für dieselbe Entität (Klasse, Vorlage, Enumeration, Inline-Funktion, statische Elementfunktion usw.)
• Unendliche Rekursion bei der Instanziierung von Templates
• Aufrufen einer Funktion mit unterschiedlichen Parametern oder Verknüpfung mit den Parametern und Verknüpfungen, für die die Funktion definiert ist.

Hoppla

• Kaskadierende Zerstörungen von Objekten mit statischer Speicherdauer
• Das Ergebnis der Zuweisung zu teilweise überlappenden Objekten
• Rekursives erneutes Eingeben einer Funktion während der Initialisierung ihrer statischen Objekte
• Virtuelle Funktionsaufrufe an rein virtuelle Funktionen eines Objekts von seinem Konstruktor oder Destruktor aus durchführen
• Bezieht sich auf nichtstatische Mitglieder von Objekten, die nicht konstruiert oder bereits zerstört wurden

Quelldatei und Vorverarbeitung

• Eine nicht leere Quelldatei, die nicht mit einem Zeilenumbruch oder mit einem umgekehrten Schrägstrich endet (vor C++11)
• Ein umgekehrter Schrägstrich, gefolgt von einem Zeichen, das nicht Teil der angegebenen Escape-Codes in einer Zeichen- oder Zeichenfolgenkonstante ist (dies ist in C++11 implementierungsdefiniert).
• Überschreitung der Implementierungsgrenzen (Anzahl verschachtelter Blöcke, Anzahl der Funktionen in einem Programm, verfügbarer Stapelplatz …)
• Numerische Präprozessorwerte, die nicht durch a dargestellt werden können long int
• Vorverarbeitungsanweisung auf der linken Seite einer funktionsähnlichen Makrodefinition
• Dynamisches Generieren des definierten Tokens in a #if Ausdruck

Einzuordnen

• Aufruf von exit während der Zerstörung eines Programms mit statischer Speicherdauer

Die Reihenfolge, in der Funktionsparameter ausgewertet werden, ist nicht spezifiziert Verhalten. (Dies wird Ihr Programm nicht zum Absturz bringen, explodieren oder Pizza bestellen … im Gegensatz zu nicht definiert Verhalten.)

Die einzige Voraussetzung ist, dass alle Parameter vollständig ausgewertet werden müssen, bevor die Funktion aufgerufen wird.

Dies:

// The simple obvious one.
callFunc(getA(),getB());

Kann äquivalent dazu sein:

int a = getA();
int b = getB();
callFunc(a,b);

Oder dieses:

int b = getB();
int a = getA();
callFunc(a,b);

Es kann beides sein; es liegt am Compiler. Das Ergebnis kann abhängig von den Nebenwirkungen von Bedeutung sein.

Dem Compiler steht es frei, die Bewertungsteile eines Ausdrucks neu zu ordnen (unter der Annahme, dass die Bedeutung unverändert bleibt).

Aus der ursprünglichen Frage:

a[i] = i++;

// This expression has three parts:
(a) a[i]
(b) i++
(c) Assign (b) to (a)

// (c) is guaranteed to happen after (a) and (b)
// But (a) and (b) can be done in either order.
// See n2521 Section 5.17
// (b) increments i but returns the original value.
// See n2521 Section 5.2.6
// Thus this expression can be written as:

int rhs  = i++;
int lhs& = a[i];
lhs = rhs;

// or
int lhs& = a[i];
int rhs  = i++;
lhs = rhs;

Doppelt geprüfte Verriegelung. Und ein einfacher Fehler zu machen.

A* a = new A("plop");

// Looks simple enough.
// But this can be split into three parts.
(a) allocate Memory
(b) Call constructor
(c) Assign value to 'a'

// No problem here:
// The compiler is allowed to do this:
(a) allocate Memory
(c) Assign value to 'a'
(b) Call constructor.
// This is because the whole thing is between two sequence points.

// So what is the big deal.
// Simple Double checked lock. (I know there are many other problems with this).
if (a == null) // (Point B)
{
    Lock   lock(mutex);
    if (a == null)
    {
        a = new A("Plop");  // (Point A).
    }
}
a->doStuff();

// Think of this situation.
// Thread 1: Reaches point A. Executes (a)(c)
// Thread 1: Is about to do (b) and gets unscheduled.
// Thread 2: Reaches point B. It can now skip the if block
//           Remember (c) has been done thus 'a' is not NULL.
//           But the memory has not been initialized.
//           Thread 2 now executes doStuff() on an uninitialized variable.

// The solution to this problem is to move the assignment of 'a'
// To the other side of the sequence point.
if (a == null) // (Point B)
{
    Lock   lock(mutex);
    if (a == null)
    {
        A* tmp = new A("Plop");  // (Point A).
        a = tmp;
    }
}
a->doStuff();

// Of course there are still other problems because of C++ support for
// threads. But hopefully these are addresses in the next standard.

Mein Favorit ist “Unendliche Rekursion bei der Instanziierung von Vorlagen”, weil ich glaube, dass dies die einzige ist, bei der das undefinierte Verhalten zur Kompilierzeit auftritt.

Zuweisung an eine Konstante nach dem Strippen constness verwenden const_cast<>:

const int i = 10; 
int *p =  const_cast<int*>( &i );
*p = 1234; //Undefined

neben undefiniertes Verhaltengibt es auch das ebenso fiese implementierungsdefiniertes Verhalten.

Undefiniertes Verhalten tritt auf, wenn ein Programm etwas tut, dessen Ergebnis nicht durch den Standard spezifiziert ist.

Implementierungsdefiniertes Verhalten ist eine Aktion eines Programms, dessen Ergebnis nicht durch den Standard definiert ist, die Implementierung jedoch dokumentieren muss. Ein Beispiel ist “Multibyte-Zeichenliterale” aus der Stack Overflow-Frage Gibt es einen C-Compiler, der dies nicht kompiliert?.

Implementierungsdefiniertes Verhalten beißt Sie nur, wenn Sie mit der Portierung beginnen (aber ein Upgrade auf eine neue Version des Compilers ist auch eine Portierung!)

Variablen dürfen in einem Ausdruck nur einmal aktualisiert werden (technisch einmal zwischen Sequenzpunkten).

int i =1;
i = ++i;

// Undefined. Assignment to 'i' twice in the same expression.