In quali casi è necessario includere <cassert>?

Question

In quali casi dovremmo includere cassert?

Answer 1

Proprio come qualsiasi altro file di intestazione, è #include <cassert> quando si utilizza qualcosa dichiarato in tale file di intestazione, ad esempio assert().

Answer 2

vedere una facilmente accessibile reference

#include <iostream> 
// uncomment to disable assert() 
// #define NDEBUG 
#include <cassert> 

int main() 
{ 
    assert(2+2==4); 
    std::cout << "Execution continues past the first assert\n"; 
    assert(2+2==5); 
    std::cout << "Execution continues past the second assert\n"; 
} 

Answer 3

Insomma, non ne fanno uso; utilizzare <assert.h>.

C++ 11 rimossa alcuna garanzia formale di una "c ...." Intestazione non inquinare il namespace globale.

Non è mai stata una garanzia in pratica, e ora non è nemmeno una garanzia formale.

Quindi, con C++ 11 non c'è più alcun vantaggio immaginabile nell'uso delle varianti di intestazione "c ....", mentre c'è lo svantaggio netto e chiaro di quel codice che funziona bene con un compilatore e una versione di che compilatore, può riuscire a compilare un altro compilatore o versione, ad esempio a causa nome collisioni o diversa selezione di sovraccarico nel namespace globale.

SO, mentre cassert era piuttosto privo di significato in C++ 03 (non è possibile inserire una macro in uno spazio dei nomi), è totalmente privo di significato - anche come caso speciale di uno schema generale - in C++ 11.

---

addendum, Dec 22 2013:

Lo standard definisce ogni C++ intestazione C <Xh> intestazione in termini di CX > intestazione <, che a sua volta è definito in termini di intestazione della libreria C corrispondente.

C++ 11 §D.5/2:

“ Ogni C intestazione, ognuno dei quali ha un nome del modulo name.h, si comporta come se ogni nome collocato nello spazio dei nomi libreria standard dalla corrispondente cname l'intestazione viene posizionata nell'ambito dello spazio dei nomi globale. ”

C++ 11 §D.5/3 (esempio non normativo):

“ L'intestazione <cstdlib> fornisce sicuramente sue dichiarazioni e definizioni all'interno del namespace std. Può anche fornire questi nomi all'interno del namespace globale. L'intestazione <stdlib.h> fornisce sicuramente le stesse dichiarazioni e definizioni all'interno dello spazio dei nomi globale, proprio come nello standard C. Può anche fornire questi nomi all'interno del namespace std. ”

Stack Overflow utente C.R. ’ s commento mi ha reso consapevole che alcune versioni di g ++, come MinGW g ++ 4.7.2, sono piuttosto non standard rispetto alle intestazioni <X.h>, prive dei sovraccarichi di, ad es. sin che lo standard C++ richiede:

sapevo già che MinGW g ++ 4.7.2 anche manca del tutto funzioni come la swprintf, e che ha carenze idem nel puro libreria C++ come privo C++ 11 std::to_string. Tuttavia, le informazioni su di esso che mancavano del sovraccarico della funzione C erano nuove per me.

In pratica i sovraccarichi mancanti con g ++ significa

• ignorando il problema g ++, o

• evitando usando l'g mancanti ++ sovraccarichi,
  esempio utilizzando solo double sin(double), o

• utilizzando lo spazio std sovraccarichi
  (uno allora deve includere <cmath> per garantire la loro presenza con g ++).

Per utilizzare il g ++ std namespace Sovraccarichi qualificato, un approccio pratico è quello di definire intestazioni involucri del per questo compilatore. Ho usato questo approccio per affrontare le carenze di g ++. alla famiglia printf. Come ha osservato una volta David Wheeler, “ Tutti i problemi dell'informatica possono essere risolti con un altro livello di riferimento indiretto ” e hellip;

Quindi è possibile organizzare le cose in modo che il codice standard che utilizza gli overload sovraccarichi di g ++ compili anche con g ++. Questo regola il compilatore sullo standard, con una quantità fissa di codice.

Answer 4

assert.h definisce una funzione macro che può essere utilizzata come strumento di debug standard.