In welchen Fällen müssen wir <cassert> einschließen?

Question

In welchen Fällen sollten wir Cassert einschließen?

Answer 1

Genau wie jede andere Header-Datei, Sie #include <cassert>, wenn Sie etwas verwenden in dieser Header-Datei, wie assert() erklärt.

Answer 2

Sehen Sie eine leicht zugängliche 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

Kurz gesagt, verwenden Sie es nicht; Verwenden Sie <assert.h>.

C++ 11 löschte jegliche formale Garantie eines "c ...." - Headers, der den globalen Namespace nicht verschmutzt.

Es war nie eine Garantie in der Praxis, und jetzt ist es nicht einmal eine formelle Garantie.

Daher ist mit C++ 11 kein denkbarer Vorteil bei der Verwendung der "c ...." Header-Varianten, während es den eindeutigen und klaren Nachteil gibt, dass Code, der mit einem Compiler und einer Version von Dieser Compiler kann möglicherweise nicht mit einem anderen Compiler oder einer anderen Version kompiliert werden, z Namenskollisionen oder andere Überladungsauswahl im globalen Namespace.

SO, während cassert war ziemlich bedeutungslos in C++ 03 (Sie können nicht ein Makro in einem Namespace), es ist völlig bedeutungslos - auch als Sonderfall eines allgemeinen Schemas - in C++ 11.

---

Addendum, am 22. Dezember 2013:

Der Standard definiert jede C++ C Header <Xh> Header in Bezug auf die <cX> Header, was wiederum im Hinblick auf die definiert ist korrespondierender C-Bibliothekskopf

C++ 11 §D.5/2:

“ Jeder C-Header, von denen jeder einen Namen der folgenden Form besitzt name.h, wenn jeder Name in dem Namensraum-Standardbibliothek platziert verhält sich wie durch den entsprechenden cname Header wird innerhalb der globalen Namespace-Bereich platziert. ”

C++ 11 §D.5/3 (nicht normatives Beispiel):

“ Der Header <cstdlib> sicher std ihre Erklärungen und Definitionen im Namensraum zur Verfügung stellt. Sie können diese Namen auch im globalen Namespace angeben. Der Header <stdlib.h> stellt sicher dieselben Deklarationen und Definitionen im globalen Namespace bereit, ähnlich wie im C-Standard. Es kann diese Namen auch innerhalb des Namespace std bereitstellen. ”

Stack-Überlauf Benutzer C.R. ’ s Kommentar wurde mir bewusst, dass einige Versionen von g ++, wie MinGW g ++ 4.7.2, sind ziemlich Nicht-Standard in Bezug auf die <X.h> Header, die Überladungen von z.B. sin, dass der C++ Standard erfordert:

Ich wusste schon, dass MinGW g ++ 4.7.2 auch fehlt völlig Funktionen wie swprintf, und dass es dito Mängel in der reinen C++ Bibliothek wie fehlen C++ 11 std::to_string hat. Die Information darüber, dass die Überladungen der C-Funktion fehlten, war für mich neu.

die fehlenden Überlastungen mit g ++ In der Praxis bedeutet

• die g ++ Problem zu ignorieren, oder

• Vermeidung der fehlenden g ++ Überlastungen verwenden,
  z.B. Verwendung nur double sin(double) oder

• den std Namespace Überlastungen
  (man muss dann <cmath> umfassen ihre Anwesenheit mit g zu gewährleisten ++).

Um den g ++ std Namespace zu verwenden Überlastungen unqualifizierte, ein praktischer Ansatz ist Header Wrapper für diesen Compiler zu definieren. Ich habe diesen Ansatz verwendet, um g ++ - Unzulänglichkeiten zu beheben. an die printf Familie. Denn wie David Wheeler einmal bemerkte, “ Alle Probleme in der Informatik können durch eine andere Ebene der Indirektion gelöst werden ” & hellip;

Dann können Dinge so angeordnet werden, dass Standard-Code, der g ++ 's fehlende Überladungen verwendet, auch mit g ++ kompiliert. Dies passt den Compiler an den Standard mit einer festen Menge an Code an.

Answer 4

assert.h definiert eine Makrofunktion, die als Standard-Debugging-Tool verwendet werden kann.