preprocesador - programacion c++ pdf

¿Hay una directiva de preprocesador para detectar compatibilidad con C++ 11x?

Question

Esta pregunta ya tiene una respuesta aquí:

• ¿Cómo verifico si tengo compatibilidad con C ++ 11? 11 respuestas

Si tengo algún código en el que me gustaría usar extensiones de C ++ 11x tanto como sea posible, pero tengo una alternativa si esto no es compatible. Actualmente, la versión OSX de GCC y el compilador de VisualC tienen poca o ninguna compatibilidad con C ++ 11x, por lo que utilizo:

#if (defined(__APPLE__) || (defined(_WIN32)))
   ...fallback code without C++11x ...
#else
   ... code using C++11x ...
#endif

Y esto funciona, pero en realidad no es lo correcto, especialmente porque el compilador gcc en MacPorts HACE compatible con c ++ 11x.

¿Hay una macro #define C11X_SUPPORTED tipo #define C11X_SUPPORTED ? ¿Tal vez algo solo tiene GCC?

Answer 1

La biblioteca Boost.Config proporciona macros de preprocesador granular que puede utilizar para compilar de forma condicional en función de la presencia de una característica C ++ 11 determinada.

(Para un compilador, el soporte de C ++ 11 no necesita ser una proposición de todo o nada. Por ejemplo, considere cómo Microsoft seleccionó las características de C ++ 11 para incluir en Visual Studio 2012 según lo que ellos creían que beneficiaría más a sus clientes. )

Answer 2

Puede verificar el valor de la macro __cplusplus . Para C ++ 11, es mayor que 199711L .

Así que algo así como

#if __cplusplus > 199711L

#endif

Answer 3

__cplusplus debe definir como 199711L en 199711L anteriores a C ++ 11, 201103L en aquellos que soportan C ++ 11. Si esto es de mucha ayuda en la práctica es otra cuestión: la mayoría de los compiladores están a mitad de camino, por lo que no deberían definirlo como 201103L , incluso si admiten las características que le interesan. Y no es raro que un compilador mienta: un compilador que lo define como 199711L y no admite la export de plantillas, por ejemplo. Pero no hay una función estándar por prueba de características.

La solución más simple es simplemente no usar ninguna característica particular hasta que pueda estar seguro de que todos los compiladores la admiten. Tienes que escribir y apoyar el código alternativo de todos modos; ¿Por qué mantener dos versiones? La única excepción a esta regla pueden ser las nuevas características que afectan el rendimiento: si el compilador admite la semántica de movimiento o no. En tales casos, sugeriría un archivo de inclusión dependiente del compilador, que usted mismo debe escribir según la documentación del compilador y las pruebas personales; El hecho de que el compilador pueda documentar que admite una característica específica no significa que su soporte esté libre de errores. Simplemente cree un directorio por compilador específico, coloque este archivo allí y especifique la opción apropiada -I o /I en su archivo de proyecto o de archivo.

Y tus pruebas deberían ser algo así como:

#ifdef HAS_MOVE_SEMANTICS
...
#endif

en lugar de solo en el compilador, la versión o lo que sea.