¿En qué casos debemos incluir <cassert>?

Question

¿En qué casos deberíamos incluir cassert?

Answer 1

Al igual que cualquier otro archivo de encabezado, usted #include <cassert> cuando utiliza algo declarado en ese archivo de encabezado, como assert().

Answer 2

ve un fácil acceso 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

En resumen, no lo use; use <assert.h>.

C++ 11 eliminó cualquier garantía formal de un encabezado "c ...." que no contaminara el espacio de nombres global.

Nunca fue una garantía en la práctica, y ahora ni siquiera es una garantía formal.

Por lo tanto, con C++ 11 ya no hay ninguna ventaja concebible en el uso de las variantes de encabezado "c ....", mientras que existe la clara y clara desventaja de que el código funciona bien con un compilador y una versión de ese compilador puede no compilar con otro compilador o versión, debido, por ejemplo, a colisiones de nombres o diferentes selecciones de sobrecarga en el espacio de nombres global.

SO, mientras que cassert no tenía sentido en C++ 03 (no se puede poner una macro en un espacio de nombres), es totalmente sin sentido, incluso como un caso especial de un esquema general, en C++ 11.

---

Addendum 22 Dic 2013:

La norma define cada C++ cabecera C <Xh> cabecera en términos de la cabecera <cX>, que a su vez se define en términos de la cabecera de la biblioteca C correspondiente.

C++ 11 §D.5/2:

cabecera “ Cada C, cada uno de los cuales tiene un nombre de la forma name.h, se comporta como si cada nombre colocado en el espacio de nombres biblioteca estándar por el correspondiente cname encabezado se coloca dentro del ámbito de espacio de nombres global. ”

C++ 11 §D.5/3 (ejemplo no normativo):

“ El encabezado <cstdlib> proporciona ciertamente sus declaraciones y definiciones dentro del espacio de nombres std. También puede proporcionar estos nombres dentro del espacio de nombres global. El encabezado <stdlib.h> ciertamente proporciona las mismas declaraciones y definiciones dentro del espacio de nombres global, de forma muy similar al estándar C. También puede proporcionar estos nombres dentro del espacio de nombres std. ”

usuario C.R. ’ s comentario desbordamiento de pila me hizo consciente de que algunas versiones de g ++, como MinGW g ++ 4.7.2, son bastante no estándar con respecto a los encabezados <X.h>, que carece de las sobrecargas de, p. sin que el estándar C++ requiere:

ya que sabía que MinGW g ++ 4.7.2 también carece totalmente funciones tales como swprintf, y que tiene deficiencias ídem en el C++ puro biblioteca tales como carente de C++ 11 std::to_string. Sin embargo, la información sobre esto que carecía de las sobrecargas de la función C era nueva para mí.

En la práctica las sobrecargas que carecen con g ++ significa

• ignorar el problema g ++, o

• evitar el uso de la g faltante ++ sobrecargas,
  por ejemplo usando sólo double sin(double), o

• utilizando el espacio de nombres std sobrecarga
  (uno entonces necesita incluir <cmath> para garantizar su presencia con g ++).

Para utilizar el g ++ std espacio de nombres sobrecargas sin reservas, un enfoque práctico consiste en definir cabeceras envolturas para este compilador. He usado ese enfoque para abordar las deficiencias de g ++ wrt. a la familia printf. Como dijo una vez David Wheeler, “ Todos los problemas en la informática se pueden resolver con otro nivel de direccionamiento indirecto ” & hellip;

Luego se pueden arreglar las cosas para que el código estándar que usa las sobrecargas que faltan de g ++ también compile con g ++. Esto ajusta el compilador al estándar, con una cantidad fija de código.

Answer 4

assert.h define una función de macro que se puede utilizar como una herramienta de depuración estándar.