c++ - que - ¿Es mejor incluir<cassert> o<assert.h>?

assert.h para que sirve (2)

El contenido de <cassert> es el mismo que el encabezado de la biblioteca estándar de C <assert.h> , excepto que una macro llamada static_assert no está definida. ¹

Prefiero <cassert> .

Todos los <xxx.h> encabezados de C (incluido <assert.h> ) están en desuso:

D.5 encabezados de biblioteca estándar [depr.c.headers]

Actualización sobre la macro static_assert desde C

En D.5 [depr.c.headers], el estándar de C ++ se refiere a los encabezados <xxx.h> como "los encabezados de C :

1 Para compatibilidad con la biblioteca estándar de C, la biblioteca estándar de C ++ proporciona los encabezados de C que se muestran en la Tabla 141.

En C ++ 14, la especificación hace referencia a C99 (ISO / IEC 9899: 1999). C99 no definió la macro static_assert (en ningún encabezado). C ++ 14 tenía esto que decir acerca de <cassert> en 19.3 [aserciones]:

2 El contenido es el mismo que el encabezado de la biblioteca C estándar <assert.h> .

C ++ 17 hace referencia a C11 (SO / IEC 9899: 2011) que define static_assert en <assert.h> , y tiene esto que decir sobre <cassert> en 22.3.1 [cassert.syn]:

1 El contenido es el mismo que el encabezado de la biblioteca estándar de C <assert.h> , excepto que una macro llamada static_assert no está definida.

Tanto C ++ 14 como C ++ 17 definen <assert.h> solo por referencia a sus respectivas especificaciones de C, y también por esto:

Ver también: ISO C 7.2.

(que es la sección C que especifica <assert.h> )

La forma en que leí esto, técnicamente <assert.h> , cuando se compila con un compilador de C ++ 17, en realidad define una macro llamada static_assert . Sin embargo, hacerlo no tendría sentido, y no puedo imaginar que ninguna implementación realmente se moleste en hacerlo.

En cualquier caso, mantengo mi recomendación anterior:

Prefiero <cassert> .

Es solo la forma en C ++ de hacer las cosas. Y al menos en C ++ 98/03/11/14/17, evita dependiendo de la funcionalidad en desuso. Quién sabe qué traerá C ++ 20. Pero C ++ 20 definitivamente no desaprobará <cassert> .

¹ 22.3.1 Sinopsis de encabezado [cassert.syn]

² Enlace a la especificación de C ++ 11.

³ Enlace a la especificación C ++ 17.

Esta pregunta ya tiene una respuesta aquí:

¿Debo incluir <xxxx.h> o <cxxxx> en los programas de C ++? 2 respuestas

Usando C ++ 11, ¿es mejor <cassert> o <assert.h> ? ¿O no hay diferencia?

Editar:

Parece que debería incluir <xxxx.h> o <cxxxx> en los programas de C ++? Argumenta que todo se reduce a contaminar el espacio de nombres global. ¿Es este un caso especial porque assert es una macro y no hay std::assert ?

Mirando el código:

Using assert.h // Compatible with C language standard --------------- #include <assert.h> int main() { assert(true == true); // Execution continues assert(true == false); // Execution will abort with false value assert! return 0; } Using cassert // Not compatible with C language standard -------------- #include <cassert> int main() { assert(true == true); // Execution continues assert(true == false); // Execution will abort with false value assert! return 0; }

¡Ambos trabajan!

¿Cuál es mejor en C ++ 11?

Con respecto a la especificación de C ++ 11 y C ++ 17 :

C.5.1 (sección del documento C ++ 17)
Modificaciones a los encabezados [dif.mods.to.headers]
Para compatibilidad con la biblioteca estándar de C, la biblioteca estándar de C ++ proporciona los encabezados de C enumerados en D.5, pero su uso está en desuso en C ++.
No hay encabezados de C ++ para los encabezados de C, <stdnoreturn.h> y <threads.h> , ni los encabezados de C forman parte de C ++.
Los encabezados C ++ (D.4.1) y (D.4.4), así como sus encabezados C correspondientes, no contienen ninguno de los contenidos de la biblioteca estándar de C y, en su lugar, solo incluyen otros encabezados de la biblioteca estándar de C ++.

D.5 Encabezados de biblioteca estándar C [depr.c.headers] 1. Para compatibilidad con la biblioteca estándar C, la biblioteca estándar C ++ proporciona los encabezados C que se muestran en la Tabla 141.

Los documentos de especificaciones estándar de C ++ 11 y C ++ 17 establecen que el uso de <Xh> sigue siendo compatible con el estándar C, aunque su uso se considera obsoleto .

Respecto a la open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0619r0.html#3.5

Ellos están revisando "en desuso" el uso de los encabezados de la biblioteca C en C ++ 20. <Xh> aparece resaltado en verde. La desaprobación de C ++ 11 y C ++ 17, a partir de ahora, se declara como una "recomendación débil" y una "modificación" para mantener los " encabezados de biblioteca estándar C (c.headers) " se muestra a continuación:

"Los encabezados básicos de la biblioteca C son una característica de compatibilidad esencial, y no irán a ninguna parte pronto". (del open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0619r0.html#3.5 )

Estándar D.5 C
encabezados de biblioteca [depr.c.headers]
Recomendación débil: además de lo anterior, también elimine los encabezados C correspondientes del estándar C ++, por mucho que no tengamos <stdatomic.h> , <stdnoreturn.h> o <threads.h> . Como arriba, pero con los siguientes ajustes: 20.5.5.2.1 encabezados de biblioteca estándar C [encabezados]
Para compatibilidad con la biblioteca estándar de C, la biblioteca estándar de C ++ proporciona los encabezados de C que se muestran en la Tabla 141. Tabla 141: encabezados de C

<assert.h> <inttypes.h> <signal.h> <stdio.h> <wchar.h> <complex.h> <iso646.h> <stdalign.h> <stdlib.h> <wctype.h> <ctype.h> <limits.h> <stdarg.h> <string.h> <errno.h> <locale.h> <stdbool.h> <tgmath.h> <fenv.h> <math.h> <stddef.h> <time.h> <float.h> <setjmp.h> <stdint.h> <uchar.h>

El encabezado <complex.h> comporta como si simplemente incluyera el encabezado. El encabezado <tgmath.h> comporta como si simplemente incluyera los encabezados <complex> y <cmath> .

Bjarne Stroustrup recomienda maximizar la interoperabilidad entre los lenguajes C y C ++ , reduciendo las incompatibilidades tanto como sea posible. Otros argumentan lo contrario, ya que complica las cosas.

Entonces, parece que <Xh> no van a ninguna parte . En última instancia, puede utilizar ambos. Personalmente, tomaría la decisión de cuál utilizaría para hacer que su código fuera compatible con el código C o no.