¿Puede el código C ++ ser válido tanto en C ++ 03 como en C ++ 11 pero hacer cosas diferentes?

¿Es posible que el código C ++ cumpla tanto con el estándar C ++ 03 como con el estándar C ++ 11 , pero hacer cosas diferentes según bajo qué estándar se esté compilando?

La respuesta es un sí rotundo. En el lado positivo hay:

• El código que antes copiaba implícitamente objetos ahora los moverá implícitamente cuando sea posible.

En el lado negativo, se enumeran varios ejemplos en el apéndice C de la norma. Aunque hay muchos más negativos que positivos, cada uno de ellos es mucho menos probable que ocurra.

Literales de cadena

#define u8 "abc"
const char* s = u8"def"; // Previously "abcdef", now "def"

y

#define _x "there"
"hello "_x // Previously "hello there", now a user defined string literal

Tipo de conversiones de 0

En C ++ 11, solo los literales son constantes de puntero nulo enteros:

void f(void *); // #1
void f(...); // #2
template<int N> void g() {
    f(0*N); // Calls #2; used to call #1
}

Resultados redondeados después de la división de enteros y el módulo

En C ++ 03 se permitió al compilador redondear hacia 0 o hacia el infinito negativo. En C ++ 11 es obligatorio redondear hacia 0

int i = (-1) / 2; // Might have been -1 in C++03, is now ensured to be 0

Espacios en blanco entre llaves de cierre de plantilla anidadas >> vs>>

Dentro de una especialización o instanciación >>, en cambio, podría interpretarse como un desplazamiento a la derecha en C ++ 03. Sin embargo, es más probable que esto rompa el código existente: (de http://gustedt.wordpress.com/2013/12/15/a-disimprovement-observed-from-the-outside-right-angle-brackets/ )

template< unsigned len > unsigned int fun(unsigned int x);
typedef unsigned int (*fun_t)(unsigned int);
template< fun_t f > unsigned int fon(unsigned int x);

void total(void) {
    // fon<fun<9> >(1) >> 2 in both standards
    unsigned int A = fon< fun< 9 > >(1) >>(2);
    // fon<fun<4> >(2) in C++03
    // Compile time error in C++11
    unsigned int B = fon< fun< 9 >>(1) > >(2);
}

El operador newahora puede lanzar otras excepciones questd::bad_alloc

struct foo { void *operator new(size_t x){ throw std::exception(); } }
try {
    foo *f = new foo();
} catch (std::bad_alloc &) {
    // c++03 code
} catch (std::exception &) {
    // c++11 code
}

Los destructores declarados por el usuario tienen un ejemplo de especificación de excepción implícita de ¿Qué cambios importantes se introducen en C ++ 11?

struct A {
    ~A() { throw "foo"; } // Calls std::terminate in C++11
};
//...
try { 
    A a; 
} catch(...) { 
    // C++03 will catch the exception
} 

size() de contenedores ahora se requiere para funcionar en O (1)

std::list<double> list;
// ...
size_t s = list.size(); // Might be an O(n) operation in C++03

std::ios_base::failureno deriva directamente de std::exceptionmás

Si bien la clase base directa es nueva, std::runtime_errorno lo es. Así:

try {
    std::cin >> variable; // exceptions enabled, and error here
} catch(std::runtime_error &) {
    std::cerr << "C++11\n";
} catch(std::ios_base::failure &) {
    std::cerr << "Pre-C++11\n";
}

Le señalo este artículo y el seguimiento , que tiene un buen ejemplo de cómo se >>puede cambiar el significado de C ++ 03 a C ++ 11 mientras se compila en ambos.

bool const one = true;
int const two = 2;
int const three = 3;

template<int> struct fun {
    typedef int two;
};

template<class T> struct fon {
    static int const three = ::three;
    static bool const one = ::one;
};

int main(void) {
    fon< fun< 1 >>::three >::two >::one; // valid for both  
}

La parte clave es la línea in main, que es una expresión.

En C ++ 03:

1 >> ::three = 0
=> fon< fun< 0 >::two >::one;

fun< 0 >::two = int
=> fon< int >::one

fon< int >::one = true
=> true

En C ++ 11

fun< 1 > is a type argument to fon
fon< fun<1> >::three = 3
=> 3 > ::two > ::one

::two is 2 and ::one is 1
=> 3 > 2 > 1
=> (3 > 2) > 1
=> true > 1
=> 1 > 1
=> false

Felicitaciones, dos resultados diferentes para la misma expresión. Por supuesto, el C ++ 03 presentó un formulario de advertencia Clang cuando lo probé.

Sí, hay varios cambios que harán que el mismo código dé como resultado un comportamiento diferente entre C ++ 03 y C ++ 11. Las diferencias en las reglas de secuenciación provocan algunos cambios interesantes, incluido un comportamiento previamente indefinido que se vuelve bien definido.

1. múltiples mutaciones de la misma variable dentro de una lista de inicializadores

Un caso de esquina muy interesante sería múltiples mutaciones de la misma variable dentro de una lista de inicializador, por ejemplo:

int main()
{
    int count = 0 ;
    int arrInt[2] = { count++, count++ } ;

    return 0 ;
}

Tanto en C ++ 03 como en C ++ 11 esto está bien definido, pero el ¿Hay múltiples mutaciones de la misma variable dentro de las listas de inicializadores comportamiento indefinido antes de C ++ 11? pero en ¿Las mutaciones múltiples dentro de las listas de inicializadores tienen un comportamiento indefinido? . Entonces, si compilamos usando clangen modo C ++ 03, brinda la siguiente advertencia ( véalo en vivo ):

warning: multiple unsequenced modifications to 'count' [-Wunsequenced]

    int arrInt[2] = { count++, count++ } ;

                           ^        ~~

pero no proporciona una advertencia en C ++ 11 ( verlo en vivo ).

2. Las nuevas reglas de secuenciación hacen que i = ++ i + 1; bien definido en C ++ 11

Las nuevas reglas de secuenciación adoptadas después de C ++ 03 significan que:

int i = 0 ;
i = ++ i + 1;

ya no es un comportamiento indefinido en C ++ 11, esto se trata en el informe de defectos 637. Las reglas de secuenciación y el ejemplo no están de acuerdo

3. Las nuevas reglas de secuenciación también hacen ++++ i; bien definido en C ++ 11

Las nuevas reglas de secuenciación adoptadas después de C ++ 03 significan que:

int i = 0 ;
++++i ;

ya no es un comportamiento indefinido en C ++ 11.

4. Desplazamientos a la izquierda firmados un poco más sensatos

Los borradores posteriores de C ++ 11 incluyen los N3485que enlazo a continuación y corrigieron el comportamiento indefinido de cambiar un bit 1 dentro o más allá del bit de signo . Esto también se trata en el informe de defectos 1457 . Howard Hinnant comentó sobre la importancia de este cambio en el hilo de ¿Es el desplazamiento a la izquierda (<<) un comportamiento indefinido de entero negativo en C ++ 11?.

5. Las funciones constexpr se pueden tratar como expresiones constantes de tiempo de compilación en C ++ 11

C ++ 11 introdujo funciones constexpr que:

El especificador constexpr declara que es posible evaluar el valor de la función o variable en tiempo de compilación. Estas variables y funciones se pueden utilizar cuando solo se permiten expresiones de constantes de tiempo de compilación.

mientras que C ++ 03 no tiene la característica constexpr , no tenemos que usar explícitamente la palabra clave constexpr ya que la biblioteca estándar proporciona muchas funciones en C ++ 11 como constexpr . Por ejemplo, std :: numeric_limits :: min . Lo que puede llevar a comportamientos diferentes, por ejemplo:

#include <limits>

int main()
{
    int x[std::numeric_limits<unsigned int>::min()+2] ;
}

Si se usa clangen C ++ 03, esto hará xque sea una matriz de longitud variable, que es una extensión y generará la siguiente advertencia:

warning: variable length arrays are a C99 feature [-Wvla-extension]
    int x[std::numeric_limits<unsigned int>::min()+2] ;
         ^

mientras que en C ++ 11 std::numeric_limits<unsigned int>::min()+2es una expresión constante de tiempo de compilación y no requiere la extensión VLA.

6. En C ++ 11, no se generan implícitamente especificaciones de excepción para sus destructores

Dado que en C ++ 11 el destructor definido por el usuario tiene una noexcept(true)especificación implícita como se explica en noexcept destructors , significa que el siguiente programa:

#include <iostream>
#include <stdexcept>

struct S
{
  ~S() { throw std::runtime_error(""); } // bad, but acceptable
};

int main()
{
  try { S s; }
  catch (...) {
    std::cerr << "exception occurred";
  } 
 std::cout << "success";
}

En C ++ 11 llamará std::terminatepero se ejecutará correctamente en C ++ 03.

7. En C ++ 03, los argumentos de la plantilla no podían tener vínculos internos.

Esto se explica muy bien en Por qué std :: sort no acepta clases de comparación declaradas dentro de una función . Entonces, el siguiente código no debería funcionar en C ++ 03:

#include <iostream>
#include <vector>
#include <algorithm>

class Comparators
{
public:
    bool operator()(int first, int second)
    {
        return first < second;
    }
};

int main()
{
    class ComparatorsInner : public Comparators{};

    std::vector<int> compares ;
    compares.push_back(20) ;
    compares.push_back(10) ;
    compares.push_back(30) ;

    ComparatorsInner comparatorInner;
    std::sort(compares.begin(), compares.end(), comparatorInner);

    std::vector<int>::iterator it;
    for(it = compares.begin(); it != compares.end(); ++it)
    {
        std::cout << (*it) << std::endl;
    }
}

pero actualmente clangpermite este código en modo C ++ 03 con una advertencia a menos que use -pedantic-errorsflag, que es un poco asqueroso, véalo en vivo .

8. >> ya no está mal formado al cerrar varias plantillas

El uso >>para cerrar varias plantillas ya no está mal formado, pero puede generar un código con resultados diferentes en C ++ 03 y C + 11. El siguiente ejemplo se toma de corchetes en ángulo recto y compatibilidad con versiones anteriores :

#include <iostream>
template<int I> struct X {
  static int const c = 2;
};
template<> struct X<0> {
  typedef int c;
};
template<typename T> struct Y {
  static int const c = 3;
};
static int const c = 4;
int main() {
  std::cout << (Y<X<1> >::c >::c>::c) << '\n';
  std::cout << (Y<X< 1>>::c >::c>::c) << '\n';
}

y el resultado en C ++ 03 es:

0
3

y en C ++ 11:

0
0

9. C ++ 11 cambia algunos de los constructores std :: vector

El código ligeramente modificado de esta respuesta muestra que el uso del siguiente constructor de std :: vector :

std::vector<T> test(1);

produce diferentes resultados en C ++ 03 y C ++ 11:

#include <iostream>
#include <vector>

struct T
{
    bool flag;
    T() : flag(false) {}
    T(const T&) : flag(true) {}
};


int main()
{
    std::vector<T> test(1);
    bool is_cpp11 = !test[0].flag;

    std::cout << is_cpp11 << std::endl ;
}

10. Reducción de conversiones en inicializadores agregados

En C ++ 11, una conversión de restricción en inicializadores agregados está mal formada y parece que gccpermite esto tanto en C ++ 11 como en C ++ 03, aunque proporciona una advertencia de forma predeterminada en C ++ 11:

int x[] = { 2.0 };

Esto se trata en el párrafo 3 de 8.5.4 Inicialización de lista de la sección estándar de C ++ 11 :

La inicialización de lista de un objeto o referencia de tipo T se define como sigue:

y contiene la siguiente viñeta (el énfasis es mío ):

De lo contrario, si T es un tipo de clase, se consideran los constructores. Se enumeran los constructores aplicables y se elige el mejor mediante resolución de sobrecarga (13.3, 13.3.1.7). Si se requiere una conversión de restricción (ver más abajo) para convertir cualquiera de los argumentos, el programa está mal formado

Esta y muchas más instancias se tratan en la sección del borrador del estándar annex C.2 C ++ C ++ e ISO C ++ 2003 . También incluye:

• Nuevos tipos de literales de cadena [...] Específicamente, las macros denominadas R, u8, u8R, u, uR, U, UR o LR no se expandirán cuando estén adyacentes a un literal de cadena, pero se interpretarán como parte del literal de cadena . Por ejemplo

  #define u8 "abc"
  const char *s = u8"def"; // Previously "abcdef", now "def"
  

• Soporte de cadenas literales definidas por el usuario [...] Anteriormente, el # 1 habría consistido en dos tokens de preprocesamiento separados y la macro _x se habría expandido. En esta Norma Internacional, el n. ° 1 consta de un solo token de preprocesamiento, por lo que la macro no se expande.

  #define _x "there"
  "hello"_x // #1
  

• Especificar el redondeo para los resultados del código entero / y% [...] 2003 que usa división de enteros redondea el resultado hacia 0 o hacia el infinito negativo, mientras que esta Norma Internacional siempre redondea el resultado hacia 0.

• La complejidad de las funciones de los miembros size () ahora es constante [...] Algunas implementaciones de contenedores que cumplen con C ++ 2003 pueden no cumplir con los requisitos de size () especificados en esta Norma Internacional. El ajuste de contenedores como std :: list a los requisitos más estrictos puede requerir cambios incompatibles.

• Cambiar la clase base de std :: ios_base :: failure [...] std :: ios_base :: failure ya no se deriva directamente de std :: exception, sino que ahora se deriva de std :: system_error, que a su vez se deriva de std :: runtime_error. El código C ++ 2003 válido que asume que std :: ios_base :: failure se deriva directamente de std :: exception puede ejecutarse de manera diferente en esta Norma Internacional.

Un cambio potencialmente peligroso e incompatible con versiones anteriores es en los constructores de contenedores de secuencia como std::vector, específicamente, en la sobrecarga que especifica el tamaño inicial. Mientras que en C ++ 03, copiaron un elemento construido por defecto, en C ++ 11 construyeron por defecto cada uno.

Considere este ejemplo (usando boost::shared_ptrpara que sea válido C ++ 03):

#include <deque>
#include <iostream>

#include "boost/shared_ptr.hpp"


struct Widget
{
  boost::shared_ptr<int> p;

  Widget() : p(new int(42)) {}
};


int main()
{
  std::deque<Widget> d(10);
  for (size_t i = 0; i < d.size(); ++i)
    std::cout << "d[" << i << "] : " << d[i].p.use_count() << '\n';
}

Ejemplo en vivo de C ++ 03

Ejemplo en vivo de C ++ 11

La razón es que C ++ 03 especificó una sobrecarga para "especificar tamaño y elemento de prototipo" y "especificar tamaño solamente", así (los argumentos del asignador se omiten por brevedad):

container(size_type size, const value_type &prototype = value_type());

Esto siempre se copiará prototypeen los sizetiempos del contenedor . Cuando se llama con un solo argumento, creará sizecopias de un elemento construido por defecto.

En C ++ 11, esta firma de constructor se eliminó y se reemplazó con estas dos sobrecargas:

container(size_type size);

container(size_type size, const value_type &prototype);

El segundo funciona como antes, creando sizecopias del prototypeelemento. Sin embargo, el primero (que ahora maneja llamadas con solo el argumento de tamaño especificado) construye por defecto cada elemento individualmente.

Supongo que la razón de este cambio es que la sobrecarga de C ++ 03 no se podría usar con un tipo de elemento de solo movimiento. Pero es un cambio radical, no obstante, y rara vez se documenta en eso.

El resultado de una lectura fallida de un std::istreamha cambiado. CppReference lo resume muy bien:

Si la extracción falla (por ejemplo, si se ingresó una letra donde se esperaba un dígito), valuese deja sin modificar y failbitse establece. (hasta C ++ 11)

Si la extracción falla, se escribe cero valuey failbitse establece. Si la extracción da como resultado un valor demasiado grande o demasiado pequeño para caber value, std::numeric_limits<T>::max()o std::numeric_limits<T>::min()se escribe y failbitse establece el indicador. (desde C ++ 11)

Esto es principalmente un problema si está acostumbrado a la nueva semántica y luego tiene que escribir usando C ++ 03. Lo siguiente no es una práctica particularmente buena, pero está bien definida en C ++ 11:

int x, y;
std::cin >> x >> y;
std::cout << x + y;

Sin embargo, en C ++ 03, el código anterior usa una variable no inicializada y por lo tanto tiene un comportamiento indefinido.

Este hilo ¿Qué diferencias, si las hay, entre C ++ 03 y C ++ 0x se pueden detectar en tiempo de ejecución? Tiene ejemplos (copiados de ese hilo) para determinar las diferencias de idioma, por ejemplo, aprovechando el colapso de referencias de C ++ 11:

template <class T> bool f(T&) {return true; } 
template <class T> bool f(...){return false;} 

bool isCpp11() 
{
    int v = 1;
    return f<int&>(v); 
}

y c ++ 11 que permite tipos locales como parámetros de plantilla:

template <class T> bool cpp11(T)  {return true;} //T cannot be a local type in C++03
                   bool cpp11(...){return false;}

bool isCpp0x() 
{
   struct local {} var; //variable with local type
   return cpp11(var);
}

Aquí hay otro ejemplo:

#include <iostream>

template<class T>
struct has {
  typedef char yes;
  typedef yes (&no)[2];    
  template<int> struct foo;    
  template<class U> static yes test(foo<U::bar>*);      
  template<class U> static no  test(...);    
  static bool const value = sizeof(test<T>(0)) == sizeof(yes);
};

enum foo { bar };

int main()
{
    std::cout << (has<foo>::value ? "yes" : "no") << std::endl;
}

Huellas dactilares:

Using c++03: no
Using c++11: yes

Ver el resultado en Coliru