¿Qué cambios importantes se introducen en C ++ 11?

Sé que al menos uno de los cambios en C ++ 11 que hará que el código antiguo deje de compilarse: la introducción de explicit operator bool()en la biblioteca estándar, reemplazando las instancias antiguas de operator void*(). Por supuesto, el código que esto romperá es probablemente código que no debería haber sido válido en primer lugar, pero sigue siendo un cambio importante: los programas que solían ser válidos ya no lo son.

¿Hay otros cambios importantes?

El FDIS tiene una sección para incompatibilidades, en el apéndice C.2"C ++ e ISO C ++ 2003".

Resumen, parafraseando el FDIS aquí, para que sea (mejor) adecuado como respuesta SO. Agregué algunos ejemplos propios para ilustrar las diferencias.

Hay algunas incompatibilidades relacionadas con la biblioteca de las que no conozco exactamente las implicaciones, así que las dejo para que otros las expliquen.

Lenguaje principal

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

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

Nuevas palabras clave: alignas, alignof, char16_t, char32_t, constexpr, decltype, noexcept, nullptr, static_assert y thread_local

Ciertos literales enteros más grandes que los que se pueden representar con long podrían cambiar de un tipo entero sin signo a long long con signo.

El código válido de C ++ 2003 que utiliza la división de enteros redondea el resultado hacia 0 o hacia el infinito negativo, mientras que C ++ 0x siempre redondea el resultado hacia 0.

(es cierto que no es realmente un problema de compatibilidad para la mayoría de las personas).

El código válido de C ++ 2003 que usa la palabra clave autocomo un especificador de clase de almacenamiento puede no ser válido en C ++ 0x.

Las conversiones estrechas provocan incompatibilidades con C ++ 03. Por ejemplo, el siguiente código es válido en C ++ 2003 pero no es válido en esta Norma Internacional porque de doble a int es una conversión de restricción:

int x[] = { 2.0 };

Las funciones miembro especiales declaradas implícitamente se definen como eliminadas cuando la definición implícita no hubiera estado bien formada.

Un programa válido de C ++ 2003 que utiliza una de estas funciones miembro especiales en un contexto donde la definición no es necesaria (por ejemplo, en una expresión que no se evalúa potencialmente) se vuelve mal formado.

Ejemplo mío:

struct A { private: A(); };
struct B : A { };
int main() { sizeof B(); /* valid in C++03, invalid in C++0x */ }

Algunos SFINAE han utilizado trucos de este tamaño, y deben cambiarse ahora :)

Los destructores declarados por el usuario tienen una especificación de excepción implícita.

Ejemplo mío:

struct A {
  ~A() { throw "foo"; }
};

int main() { try { A a; } catch(...) { } }

Este código llama terminateen C ++ 0x, pero no en C ++ 03. Porque la especificación de excepción implícita de A::~Aen C ++ 0x es noexcept(true).

Una declaración válida de C ++ 2003 que contiene exportestá mal formada en C ++ 0x.

Una expresión válida de C ++ 2003 que contiene >seguida inmediatamente por otra >puede ahora tratarse como cerrar dos plantillas.

En C ++ 03, >>siempre sería el token de operador de turno.

Permitir llamadas dependientes de funciones con vinculación interna.

Ejemplo mío:

static void f(int) { }
void f(long) { }

template<typename T>
void g(T t) { f(t); }

int main() { g(0); }

En C ++ 03, esto llama f(long), pero en C ++ 0x, llama f(int). Cabe señalar que tanto en C ++ 03 como en C ++ 0x, las siguientes llamadas f(B)(el contexto de instanciación todavía solo considera declaraciones de vinculación externas).

struct B { };
struct A : B { };

template<typename T>
void g(T t) { f(t); }

static void f(A) { }
void f(B) { }

int main() { A a; g(a); }

f(A)No se toma la mejor correspondencia , porque no tiene vinculación externa.

Cambios en la biblioteca

El código válido de C ++ 2003 que utiliza cualquier identificador agregado a la biblioteca estándar de C ++ de C ++ 0x puede fallar al compilar o producir resultados diferentes en esta norma internacional.

El código C ++ 2003 válido que los #includesencabezados con nombres de nuevos encabezados de biblioteca estándar C ++ 0x pueden no ser válidos en esta Norma Internacional.

El código válido de C ++ 2003 que se ha compilado esperando que se realice el intercambio <algorithm>puede tener que incluir en su lugar<utility>

El espacio de nombres global posixahora está reservado para la estandarización.

Válido código C ++ 2003 que define override, final, carries_dependency, o noreturncomo macros no son válidos en C ++ 0x.

El significado de la palabra clave auto cambió.

¿Rompiendo el cambio?

Bueno, por un lado, si se ha utilizado decltype, constexpr, nullptr, etc, como identificadores entonces usted puede estar en problemas ...

Algunas incompatibilidades básicas que no están cubiertas por la sección de incompatibilidades:

C ++ 0x trata el nombre de la clase inyectada como una plantilla, si el nombre se pasa como un argumento a un parámetro de plantilla de plantilla, y como un tipo si se pasa a un parámetro de tipo de plantilla.

El código C ++ 03 válido puede comportarse de manera diferente si se basa en que el nombre de la clase inyectada sea siempre un tipo en estos escenarios. Código de ejemplo tomado de mi clang PR

template<template<typename> class X>
struct M { };

template<template<typename> class X>
void g(int = 0); // #1

template<typename T>
void g(long = 0); // #2

template<typename T>
struct A {
  void f() {
    g<A>(); /* is ambiguous in C++0x */
    g<A>(1); /* should choose #1 in C++0x */
  }
};

void h() {
  A<int> a;
  a.f();
}

En C ++ 03, el código llama al segundo en gambas ocasiones.

C ++ 0x hace que algunos nombres que eran dependientes en C ++ 03 ahora sean no dependientes. Y requiere que la búsqueda de nombres para nombres calificados no dependientes que se refieran a miembros de la plantilla de clase actual se repita en la instanciación, y requiere la verificación de que estos nombres se busquen de la misma manera que en el contexto de definición de la plantilla.

Es posible que el código C ++ 03 válido que depende de la regla de dominio ya no se compile debido a este cambio.

Ejemplo:

struct B { void f(); };

template<typename T>
struct A : virtual B { void f(); };

template<typename T>
struct C : virtual B, A<T> {
  void g() { this->f(); }
};

int main() { C<int> c; c.g(); }

Este código C ++ 03 válido que llama A<int>::fno es válido en C ++ 0x, porque la búsqueda de nombres al crear una instancia encontrará A<int>::fen lugar de B::f, lo que provocará un conflicto con la búsqueda en la definición.

En este punto, no está claro si eso es un defecto en el FDIS. El comité es consciente de esto y evaluará la situación.

Una declaración using donde la última parte es la misma que el identificador en la última parte del calificador en el nombre calificado que denota una clase base, que la declaración using ahora nombra al constructor, en lugar de a los miembros con ese nombre.

Ejemplo:

struct A { protected: int B; };
typedef A B;

struct C : B {
  // inheriting constructor, instead of bringing A::B into scope
  using B::B;
};

int main() { C c; c.B = 0; }

El código de ejemplo anterior está bien formado en C ++ 03, pero mal formado en C ++ 0x, ya A::Bque todavía es inaccesible en main.

Los fallos en la extracción de corrientes se tratan de forma diferente.

Ejemplo

#include <sstream>
#include <cassert>

int main()
{
   std::stringstream ss;
   ss << '!';
   
   int x = -1;
   
   assert(!(ss >> x)); // C++03 and C++11
   assert(x == -1);    // C++03
   assert(x == 0);     // C++11
}

Propuesta de cambio

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3246.html#23

Referencia estándar

[C++03: 22.2.2.1.2/11]: El resultado del procesamiento de la etapa 2 puede ser uno de

• Se ha acumulado una secuencia de caracteres en la etapa 2 que se convierte (de acuerdo con las reglas de scanf) a un valor del tipo de val. Este valor se almacena valy ios_base::goodbitse almacena en err.
• La secuencia de caracteres acumulados en la etapa 2 habría provocado scanfque se informara de una falla de entrada. ios_base::failbitestá asignado a err. [ed: No hay nada almacenado en val.]

[C++11: 22.4.2.1.2/3]: [..] El valor numérico que se almacenará puede ser uno de los siguientes:

• cero, si la función de conversión no logra convertir todo el campo . ios_base::failbitestá asignado a err.
• el valor representable más positivo, si el campo representa un valor positivo demasiado grande para ser representado val. ios_base::failbitestá asignado a err.
• el valor representable más negativo o cero para un tipo entero sin signo, si el campo representa un valor negativo demasiado grande para ser representado val. ios_base::failbitestá asignado a err.
• el valor convertido, de lo contrario.

El valor numérico resultante se almacena en formato val.

Implementaciones

• GCC 4.8 produce correctamente para C ++ 11 :

  La afirmación `x == -1 'falló

• GCC 4.5-4.8 toda la salida para C ++ 03 es lo siguiente, que parecería ser un error:

  La afirmación `x == -1 'falló

• Visual C ++ 2008 Express genera correctamente las salidas para C ++ 03:

  Afirmación fallida: x == 0

• Visual C ++ 2012 Express genera resultados incorrectos para C ++ 11, lo que parecería ser un problema de estado de implementación:

  Afirmación fallida: x == 0

¿Cómo es la introducción de operadores de conversión explícitos un cambio radical? La versión anterior seguirá siendo tan "válida" como antes.

Sí, el cambio de operator void*() consta explicit operator bool() constserá un cambio rotundo, pero solo si se usa de una manera incorrecta por sí misma. El código conforme no se romperá.

Ahora, otro cambio importante es la prohibición de reducir las conversiones durante la inicialización agregada :

int a[] = { 1.0 }; // error

Editar : Solo recordatorio, std::identity<T>se eliminará en C ++ 0x (consulte la nota). Es una estructura de conveniencia para hacer que los tipos sean dependientes. Dado que la estructura realmente no hace mucho, esto debería solucionarlo:

template<class T>
struct identity{
  typedef T type;
};

Hay numerosos cambios en la biblioteca de contenedores que permiten un código más eficiente pero rompen silenciosamente la compatibilidad con versiones anteriores para algunos casos de esquina.

Considere, por ejemplo, la std::vectorconstrucción predeterminada, C ++ 0x y los cambios importantes .

Ha habido mucha discusión sobre el movimiento implícito que rompe la compatibilidad con versiones anteriores

( una página anterior con una discusión relevante )

Si lee los comentarios, el retorno de movimiento implícito también es un cambio importante.

struct x {
   x(int) {}
};

void f(auto x = 3) { }

int main() {
   f();
}

C ++ 03: válido.

C ++ 0x: error: parameter declared 'auto'