Vermeiden von Warnungen über nicht verwendete Variablen bei der Verwendung von assert() in einem Release-Build

Question 1

Manchmal wird eine lokale Variable nur zu dem Zweck verwendet, sie in einem assert() zu überprüfen, etwa so –

int Result = Func();
assert( Result == 1 );

Beim Kompilieren von Code in einem Release-Build sind assert()s normalerweise deaktiviert, sodass dieser Code möglicherweise eine Warnung ausgibt, dass Result festgelegt, aber nie gelesen wird.

Eine mögliche Problemumgehung ist –

int Result = Func();
if ( Result == 1 )
{
    assert( 0 );
}

Aber es erfordert zu viel Tipparbeit, ist nicht schön für die Augen und führt dazu, dass die Bedingung immer überprüft wird (ja, der Compiler optimiert die Überprüfung möglicherweise weg, aber trotzdem).

Ich suche nach einer alternativen Möglichkeit, dieses assert() so auszudrücken, dass die Warnung nicht ausgelöst wird, aber dennoch einfach zu verwenden ist und die Semantik von assert() nicht geändert wird.

(Die Warnung mit einem #pragma in diesem Codebereich zu deaktivieren ist keine Option, und das Verringern der Warnstufen, damit sie verschwindet, ist auch keine Option …).

Question 2

Wir verwenden ein Makro, um gezielt anzuzeigen, wenn etwas nicht verwendet wird:

#define _unused(x) ((void)(x))

Dann hätten Sie in Ihrem Beispiel:

int Result = Func();
assert( Result == 1 );
_unused( Result ); // make production build happy

Auf diese Weise (a) ist der Produktionsbuild erfolgreich und (b) ist im Code offensichtlich, dass die Variable nicht verwendet wird von Entwurf, nicht dass es nur vergessen wurde. Dies ist besonders hilfreich, wenn Parameter einer Funktion nicht verwendet werden.

Question 3

Ich könnte keine bessere Antwort geben als diese, die dieses Problem und viele mehr anspricht:

Dumme C++-Tricks: Abenteuer in Assertion

#ifdef NDEBUG
#define ASSERT(x) do { (void)sizeof(x);} while (0)
#else
#include <assert.h>
#define ASSERT(x) assert(x)
#endif

Question 4

Ab C++17 kann die Variable mit einem Attribut versehen werden.

[[maybe_unused]] int Result = Func();
assert( Result == 1 );

Sehen https://en.cppreference.com/w/cpp/language/attributes/maybe_unused für Details.

Das ist besser als die (void)Result Trick, weil Sie die Variablendeklaration direkt dekorieren, anstatt nachträglich etwas hinzuzufügen.

Question 5

Sie könnten ein weiteres Makro erstellen, mit dem Sie die Verwendung einer temporären Variablen vermeiden können:

#ifndef NDEBUG
#define Verify(x) assert(x)
#else
#define Verify(x) ((void)(x))
#endif

// asserts that Func()==1 in debug mode, or calls Func() and ignores return
// value in release mode (any braindead compiler can optimize away the comparison
// whose result isn't used, and the cast to void suppresses the warning)
Verify(Func() == 1);

Question 6

int Result = Func();
assert( Result == 1 );

Diese Situation bedeutet, dass Sie im Freigabemodus wirklich Folgendes möchten:

Func();

Aber Func ist nicht leer, dh es gibt ein Ergebnis zurück, dh es ist a Anfrage.

Vermutlich neben der Rückgabe eines Ergebnisses, Func modifiziert etwas (warum sonst die Mühe machen, es aufzurufen und sein Ergebnis nicht zu verwenden?), dh es ist a Befehl.

Bis zum Prinzip der Befehls-Abfrage-Trennung (1), Func sollte nicht gleichzeitig ein Befehl und eine Abfrage sein. Mit anderen Worten, Abfragen sollten keine Nebeneffekte haben und das “Ergebnis” von Befehlen sollte durch die verfügbaren Abfragen zum Zustand des Objekts dargestellt werden.

Cloth c;
c.Wash(); // Wash is void
assert(c.IsClean());

Ist besser als

Cloth c;
bool is_clean = c.Wash(); // Wash returns a bool
assert(is_clean);

Ersteres gibt dir keine Warnung deiner Art, letzteres schon.

Also, kurz gesagt, meine Antwort ist: Schreiben Sie keinen Code wie diesen 🙂

Aktualisierung (1): Sie haben nach Referenzen zu den . gefragt Prinzip der Befehls-Abfrage-Trennung. Wikipedia ist eher informativ. Ich habe über diese Designtechnik gelesen in Objektorientierte Softwarekonstruktion, 2. Auflage von Bertrand Meyer.

Aktualisierung (2): j_random_hacker kommentiert “OTOH, jede “Befehls”-Funktion f(), die zuvor einen Wert zurückgegeben hat, muss jetzt eine Variable last_call_to_f_succeeded oder ähnliches setzen. Dies gilt nur für Funktionen, die in ihrem Vertrag nichts versprechen, dh Funktionen, die “erfolgreich” sein könnten oder nicht, oder ein ähnliches Konzept. Mit Design by Contract, wird eine relevante Anzahl von Funktionen haben Nachbedingungen, so dass nach “Empty()” das Objekt “IsEmpty()” ist und nach “Encode()” die Nachrichtenzeichenfolge “IsEncoded()” ist, ohne dass eine Überprüfung erforderlich ist. Auf die gleiche Weise und etwas symmetrisch rufen Sie nicht vor jedem Aufruf einer Prozedur “X()” eine spezielle Funktion “IsXFeasible()” auf; weil Sie normalerweise wissen, dass Sie zum Zeitpunkt Ihres Anrufs die Voraussetzungen von X erfüllen.

Question 7

Du könntest benutzen:

Check( Func() == 1 );

Und implementieren Sie Ihre Check(bool)-Funktion nach Belieben. Es kann entweder Assert verwenden oder eine bestimmte Ausnahme auslösen, in eine Protokolldatei oder in die Konsole schreiben, verschiedene Implementierungen in Debug und Release oder eine Kombination aus allen haben.

Question 8

Mit C++17 können wir:

[[maybe_unused]] int Result = Func();

obwohl es im Vergleich zu einer Assert-Ersetzung etwas mehr Tipparbeit erfordert. Siehe diese Antwort.

Hinweis: Dies wurde hinzugefügt, da dies der erste Google-Treffer für “c++ Assertiere nicht verwendete Variable” ist.