ndk - android studio

¿Cuál es la diferencia en GCC entre-std=gnu++ 0x y-std=c++ 0x y cuál se debe usar?

Question

Tengo problemas con <stdint.h> al usar -std=c++0x en GCC 4.4.3 (para Android):

// using -std=c++0x
#include <stdint.h>
uint64_t value; // error: ''uint64_t'' does not name a type

Pero el uso de -std=gnu++0x funciona:

// using -std=gnu++0x
#include <stdint.h>
uint64_t value; // OK

¿Es <stdint.h> incompatible con C ++ 0x?

Answer 1

Por lo que puedo decir, creo que esto podría argumentarse como un error de implementación (o en realidad, dado que C ++ 0x no se publica, no es un error en sí, sino una implementación incompleta del estado actual de la próxima norma).

He aquí por qué, refiriéndose a n3225 para el comportamiento esperado de -std=c++0x :

D.7 dice

Cada encabezado C, cada uno de los cuales tiene un nombre con el nombre nombre del formulario.h, se comporta como si cada nombre colocado en el espacio de nombres de la biblioteca estándar por el encabezado cname correspondiente se ubicara dentro del alcance del espacio de nombres global

OK, hasta ahora tan fácil. ¿Qué <cstdint> en el espacio de nombres de la biblioteca estándar?

18.4.1:

typedef unsigned integer type uint64_t; // optional

¿Como opcional? 18.4.1 / 2:

El encabezado define todas las funciones, tipos y macros de la misma forma que 7.18 en el estándar C

Joder ¿Qué dice la norma C? Sacando n1256, 7.18.1.1/3:

Estos tipos son opcionales. Sin embargo, si una implementación proporciona tipos de enteros con anchos de 8, 16, 32 o 64 bits, sin bits de relleno y (para los tipos con signo) que tienen una representación de complemento a dos, de fi nirá los nombres de typedef correspondientes.

Pero -std=c++0x , seguramente en Android con -std=c++0x GCC proporciona un tipo sin signo de 64 bits sin bits de relleno: unsigned long long . Por lo <cstdint> se requiere que <cstdint> proporcione std::uint64_t y, por lo tanto, se requiere que stdint.h proporcione uint64_t en el espacio de nombres global.

Vaya, alguien me dice por qué me equivoco :-) Una posibilidad es que C ++ 0x se refiera a "ISO / IEC 9899: 1999 Lenguajes de programación - C" sin especificar una versión. ¿Puede realmente ser que (a) 7.18.1.1/3 se haya agregado en una de las CT, y también (b) C ++ 0x pretende hacer referencia a la norma original a partir de 1999, no a las enmiendas desde entonces? Dudo que alguno de estos sea el caso, pero no tengo el C99 original para verificar (a) y ni siquiera estoy seguro de cómo verificar (b).

Edición: oh, en cuanto a cuál se debe usar -std=c++0x no es realmente un modo estricto que cumpla con los estándares, ya que todavía no existe un estándar estricto. E incluso si hubiera un estándar, gcc 4.4.3 ciertamente no es una implementación completa de él. Así que no veo la gran necesidad de usarlo si -std=gnu++0x es realmente más completo , al menos en este aspecto para su combinación de versión y plataforma de gcc.

Sin embargo, gnu++0x habilitará otras extensiones GNU, que es posible que no desee que use su código. Si desea escribir C ++ 0x portátil, eventualmente querrá cambiar a -std=c++0x . Pero no creo que GCC 4.4 o cualquier otra implementación en curso de C ++ 0x sea lo suficientemente completa como para que sea práctico escribir código del estándar (borrador), de manera que se podría decir con una cara seria "Yo Estoy programando C ++ 0x, y es solo 2011! ". Así que yo diría, usa cualquiera que funcione, y entiendo que cualquiera que uses ahora, probablemente -std=c++11 a -std=c++11 eventualmente de todos modos.