<cstdint> frente a <stdint.h>

¿Cuál es la diferencia entre stdint.hy cstdint?

Ambos están disponibles en MSVC (Visual Studio 2010) y gcc-4.5.1. También ambos definen los tipos intX_t/ uintX_t(donde Xes el tamaño en bytes del tipo).

• Si el fundamento en ambos encabezados es el mismo (tipos portátiles), ¿qué decisiones debo tomar para decidir sobre uno u otro?

El stdint.hdefine cada tipo sin ningún espacio de nombres, los cstdinttipos se encuentra en el stdespacio de nombres.

• ¿Hay alguna razón para incluir o no incluir los tipos definidos en el stdespacio de nombres? ¿Qué es diferente entre los dos encabezados?

cstdintno tiene extensión de archivo y usa el cprefijo, stdint.husa la .hextensión.

• ¿Cuáles son las convenciones de nomenclatura para estos encabezados? el cprefijo indica que se trata de una biblioteca C? hay una razón para la falta de extensión de archivo en cstdint?

La intención original en C ++ 98 era que se usara <cstdint>en C ++, para evitar contaminar el espacio de nombres global (bueno, no <cstdint>en particular, eso solo se agrega en C ++ 11, pero los <c*>encabezados en general).

Sin embargo, las implementaciones persistieron en poner los símbolos en el espacio de nombres global de todos modos, y C ++ 11 ratificó esta práctica [*]. Entonces, básicamente tienes tres opciones:

• Use <cstdint>y califique completamente cada tipo de entero que use o bien, llévelo al alcance con using std::int32_t;etc. (molesto porque es detallado, pero es la forma correcta de hacerlo como para cualquier otro símbolo en la biblioteca estándar de C ++)
• Uso <stdint.h>(levemente malo porque obsoleto)
• Use <cstdint>y asuma que su implementación colocará los símbolos en el espacio de nombres global (muy mal porque no está garantizado).

En la práctica, sospecho que una gran cantidad de código molesta usa la última opción, simplemente porque es fácil de hacer por accidente en una implementación donde se <cstdint>colocan los símbolos en el espacio de nombres global. Deberías intentar usar el primero. La segunda tiene una virtud, que está garantizado poner cosas en el espacio de nombres global en lugar de solo hacerlo tal vez. No creo que eso sea particularmente útil, pero podría ahorrar algo de escritura si esa es su prioridad.

Hay una cuarta opción, #include <cstdint>seguida de la using namespace std;que a veces es útil, pero hay lugares en los que no debes poner el using namespace std;. Diferentes personas tendrán diferentes ideas sobre dónde están esos lugares, pero "en el nivel superior en un archivo de encabezado" es peor que "en el nivel superior en un archivo cpp", que es peor que "en un alcance limitado". Algunas personas nunca escriben using namespace std;en absoluto.

[*] Eso significa que los encabezados estándar de C ++ pueden poner cosas en el espacio de nombres global, pero no es obligatorio. Por lo tanto, debe evitar chocar con esos símbolos, pero en realidad no puede usarlos porque es posible que no estén allí. Básicamente, el espacio de nombres global en C ++ es un campo minado, trate de evitarlo. Se podría argumentar que el comité ha ratificado una práctica mediante implementaciones que es casi tan dañina como quedarse using namespace std;en el nivel superior en un archivo de encabezado; la diferencia es que las implementaciones solo lo hacen para símbolos en la biblioteca estándar de C, mientras using namespace std;que lo hace para C ++ -sólo símbolos también. Hay una sección en el estándar C que enumera los nombres reservados para futuras adiciones al estándar. No es una idea completamente estúpida tratar esos nombres como reservados en el espacio de nombres global de C ++ también, pero no es esencial.

Incluir las cstdintimportaciones de los nombres de los símbolos en el espacio de nombres estándar y posiblemente en el espacio de nombres global.
Incluir las stdint.himportaciones de los nombres de los símbolos en el espacio de nombres global y posiblemente en el espacio de nombres estándar.

Las características de la biblioteca estándar de C también se proporcionan en la biblioteca estándar de C ++ y, como convención general de nomenclatura, están precedidas por una c a los nombres correspondientes en la biblioteca estándar de C.

En C ++, deberías usar:

#include <cstdint>

y calificar completamente los nombres de símbolo que usa std::
mientras está en C, debe usar:

#include <stdint.h>

El anexo D (normativo) Características de compatibilidad [depr] establece:

D.6 encabezados de biblioteca estándar de C

1 Para compatibilidad con la biblioteca estándar C y C Unicode TR, la biblioteca estándar C ++ proporciona los 25 encabezados C, como se muestra en la Tabla 151.

Que incluye:

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

Y además,

2 Cada encabezado C, cada uno de los cuales tiene un nombre del formulario name.h, se comporta como si cada nombre colocado en el espacio de nombres de biblioteca estándar por el correspondiente cname headerse ubicara dentro del ámbito del espacio de nombres global. No se especifica si estos nombres se declaran o definen primero dentro del ámbito del espacio de nombres (3.3.6) del espacio de nombres std y luego se inyectan en el ámbito del espacio de nombres global mediante declaraciones de uso explícitas (7.3.3).

3 [Ejemplo: el encabezado <cstdlib>seguramente proporciona 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>seguramente proporciona las mismas declaraciones y definiciones dentro del espacio de nombres global, como en el estándar C. También puede proporcionar estos nombres dentro del espacio de nombres std. —Ejemplo final]

1. cstdintes el encabezado C ++ 11, stdint.hes el encabezado C99 (¡C y C ++ son lenguajes diferentes!)

2. MSVC 2008 no contiene stdint.hni cstdint.

3. Las implementaciones de cstdintson en su mayoría simplemente #include <stdint.h>con algunas correcciones de espacio de nombres / lenguaje.