Quais mudanças recentes são introduzidas no C ++ 11?

Eu sei que pelo menos uma das alterações no C ++ 11 que fará com que algum código antigo pare de compilar: a introdução de explicit operator bool()na biblioteca padrão, substituindo instâncias antigas deoperator void*() . É verdade que o código que isso quebrará provavelmente é um código que não deveria ter sido válido em primeiro lugar, mas ainda assim é uma mudança de quebra: os programas que costumavam ser válidos não são mais.

Existem outras mudanças de última hora?

O FDIS possui uma seção para incompatibilidades, no apêndice C.2 "C ++ e ISO C ++ 2003".

Resumo, parafraseando o FDIS aqui, para torná-lo (melhor) adequado como uma resposta SO. Adicionei alguns exemplos para ilustrar as diferenças.

Existem algumas incompatibilidades relacionadas à biblioteca nas quais eu não conheço exatamente as implicações, então deixo essas para que outras pessoas elaborem.

Linguagem 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 .

Novas palavras-chave: alignas, alignof, char16_t, char32_t, constexpr, decltype, noexcept, nullptr, static_assert e thread_local

Certos literais inteiros maiores que podem ser representados por long podem mudar de um tipo inteiro sem sinal para long long assinado.

O código C ++ 2003 válido que usa divisão inteira arredonda o resultado para 0 ou para o infinito negativo, enquanto C ++ 0x sempre arredonda o resultado para 0.

(reconhecidamente não é realmente um problema de compatibilidade para a maioria das pessoas).

O código C ++ 2003 válido que usa a palavra-chave autocomo um especificador de classe de armazenamento pode ser inválido no C ++ 0x.

Conversões limitadas causam incompatibilidades com o C ++ 03. Por exemplo, o código a seguir é válido no C ++ 2003, mas inválido neste padrão internacional, porque double to int é uma conversão restritiva:

int x[] = { 2.0 };

As funções-membro especiais declaradas implicitamente são definidas como excluídas quando a definição implícita tiver sido mal formada.

Um programa C ++ 2003 válido que usa uma dessas funções-membro especiais em um contexto em que a definição não é necessária (por exemplo, em uma expressão que não é potencialmente avaliada) fica mal formada.

Exemplo por mim:

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

Alguns truques de tamanho foram usados ​​por alguns SFINAE e precisam ser alterados agora :)

Os destruidores declarados pelo usuário têm uma especificação de exceção implícita.

Exemplo por mim:

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

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

Esse código chama terminateem C ++ 0x, mas não em C ++ 03. Porque a especificação de exceção implícita A::~Ano C ++ 0x é noexcept(true).

Uma declaração válida do C ++ 2003 contendo exportestá incorreta no C ++ 0x.

Uma expressão válida do C ++ 2003 contendo >seguida imediatamente por outra >agora pode ser tratada como o fechamento de dois modelos.

No C ++ 03, >>sempre seria o token do operador de turno.

Permite chamadas dependentes de funções com ligação interna.

Exemplo por mim:

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

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

int main() { g(0); }

No C ++ 03, isso chama f(long), mas no C ++ 0x, isso chama f(int). Deve-se observar que, tanto em C ++ 03 quanto em C ++ 0x, as seguintes chamadas f(B)(o contexto de instanciação ainda considera apenas declarações de ligação externa).

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); }

A melhor correspondência f(A)não é obtida, porque não possui ligação externa.

Alterações na biblioteca

O código C ++ 2003 válido que usa qualquer identificador adicionado à biblioteca padrão C ++ de C ++ 0x pode falhar ao compilar ou produzir resultados diferentes neste Padrão Internacional.

O código C ++ 2003 válido que #includescabeçalhos com nomes de novos cabeçalhos de biblioteca padrão C ++ 0x pode ser inválido nesta Norma.

O código C ++ 2003 válido que foi compilado esperando que a troca ocorra <algorithm>talvez precise incluir<utility>

O espaço para nome global posixagora está reservado para padronização.

Válido código C ++ 2003 que define override, final, carries_dependency, ou noreturncomo macros é inválido em C ++ 0x.

O significado da palavra-chave automática foi alterado.

Quebrando a mudança?

Bem, para uma coisa, se você usou decltype, constexpr, nullptr, etc. como identificadores, então você pode estar em apuros ...

Algumas incompatibilidades principais que não são cobertas pela seção de incompatibilidades:

O C ++ 0x trata o nome da classe injetada como um modelo, se o nome for passado como argumento para um parâmetro do modelo e como um tipo se for passado para um parâmetro do tipo modelo.

O código C ++ 03 válido pode se comportar de maneira diferente se depender do nome da classe injetada para ser sempre um tipo nesses cenários. Código de exemplo retirado do meu 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();
}

No C ++ 03, o código chama o segundo nas gduas vezes.

O C ++ 0x torna alguns nomes que eram dependentes no C ++ 03 agora não-dependentes. E exige que a pesquisa de nome de nomes qualificados não dependentes que se refira aos membros do modelo de classe atual seja repetida na instanciação e exige a verificação de que esses nomes pesquisem da mesma maneira que no contexto de definição de modelo.

O código C ++ 03 válido que depende da regra de dominância agora pode não ser mais compilado devido a essa alteração.

Exemplo:

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(); }

Esse código C ++ 03 válido que chama A<int>::fnão é válido em C ++ 0x, porque a pesquisa de nome ao instanciar será encontrada A<int>::fem oposição aB::f , causando um conflito com a pesquisa em definição.

Neste ponto, não está claro se isso é um defeito no FDIS. O comitê está ciente disso e avaliará a situação.

Uma declaração de uso em que a última parte é igual ao identificador na última parte do qualificador no nome qualificado que denota uma classe base, que usando a declaração agora nomeia o construtor, em vez de membros com esse nome.

Exemplo:

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; }

O código de exemplo acima é bem formado em C ++ 03, mas mal formado em C ++ 0x, pois A::Bainda é inacessível em main.

A falha na extração de fluxo é tratada de maneira diferente.

Exemplo

#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
}

Alterar proposta

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

Referência padrão

[C++03: 22.2.2.1.2/11]: O resultado do processamento do estágio 2 pode ser um dos

• Uma sequência de caracteres foi acumulada no estágio 2 que é convertida (de acordo com as regras de scanf) em um valor do tipo de val. Este valor é armazenado em vale ios_base::goodbité armazenado em err.
• A sequência de caracteres acumulados no estágio 2 teria causado scanfuma falha na entrada. ios_base::failbitestá atribuído a err. [ed: Nada é armazenado val.]

[C++11: 22.4.2.1.2/3]: [..] O valor numérico a ser armazenado pode ser um dos seguintes:

• zero, se a função de conversão falhar ao converter o campo inteiro . ios_base::failbitestá atribuído a err.
• o valor representável mais positivo, se o campo representar um valor positivo muito grande para ser representado val. ios_base::failbitestá atribuído a err.
• o valor representável mais negativo ou zero para um tipo inteiro não assinado, se o campo representar um valor negativo muito grande para ser representado val. ios_base::failbitestá atribuído a err.
• o valor convertido, caso contrário.

O valor numérico resultante é armazenado em val.

Implementações

• O GCC 4.8 gera corretamente para C ++ 11 :

  Falha na afirmação `x == -1 '

• GCC 4.5-4.8 toda a saída para C ++ 03 da seguinte maneira, que parece ser um bug:

  Falha na afirmação `x == -1 '

• O Visual C ++ 2008 Express gera corretamente para C ++ 03:

  Falha na asserção: x == 0

• O Visual C ++ 2012 Express gera incorretamente para o C ++ 11, o que parece ser um problema de status de implementação:

  Falha na asserção: x == 0

Como a introdução de operadores de conversão explícita é uma mudança radical? A versão antiga ainda será tão "válida" quanto antes.

Sim, a mudança de operator void*() constpara explicit operator bool() constserá uma mudança ininterrupta, mas somente se for usada de uma maneira que esteja errada por si só. O código em conformidade não será quebrado.

Agora, outra mudança importante é a proibição de restringir conversões durante a inicialização agregada :

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

Edit : Apenas lembrete, std::identity<T>será removido em C ++ 0x (veja a nota). É uma estrutura de conveniência para tornar os tipos dependentes. Como a estrutura realmente não faz muito, isso deve corrigi-lo:

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

Existem inúmeras alterações na biblioteca de contêineres que permitem códigos mais eficientes, mas interrompem silenciosamente a compatibilidade com versões anteriores para alguns casos de canto.

Considere, por exemplo, std::vectorconstrução padrão, C ++ 0x, e alterações de interrupção .

Tem havido muita discussão sobre movimentos implícitos quebrando a compatibilidade com versões anteriores

( uma página antiga com discussão relevante )

Se você ler os comentários, o retorno implícito da movimentação também será uma mudança de última hora.

struct x {
   x(int) {}
};

void f(auto x = 3) { }

int main() {
   f();
}

C ++ 03: válido.

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

Características da linguagem

1. Inicialização geral e uniforme usando {}
2. auto
3. Prevenção de estreitamento
4. constexpr
5. Faixa baseada em loop
6. nullptr
7. classe enum
8. static_assert
9. std :: initializer_list
10. Referências de valor (mover semântica)
11. >>
12. Lambdas
13. Modelos variáveis
14. Aliases de tipo e modelo
15. Caracteres Unicode
16. tipo longo longo inteiro
17. alignas e alignof
18. decltype
19. Literais de cadeia bruta
20. POD generalizado
21. Sindicatos generalizados
22. Classes locais como argumentos de modelo
23. Sintaxe do tipo de retorno de sufixo
24. [[carry_dependency]] e [[noreturn]]
25. especificador noexcept
26. operador noexcept.
27. Recursos do C99:
    • tipos integrais estendidos
    • concatenação de cadeia estreita / larga
    • _ _ STDC_HOSTED _ _
    • _Pragma (X)
    • macros vararg e argumentos de macro vazios
28. _ _ func _ _
29. Namespaces embutidos
30. Delegando Construtores
31. Inicializadores de membros da classe
32. padrão e excluir
33. Operadores de conversão explícitos
34. Literais definidos pelo usuário
35. Modelos externos
36. Argumentos de modelo padrão para modelos de função
37. Herança de construtores
38. substituição e final
39. Regra SFINAE mais simples e mais geral
40. Modelo de memória
41. thread_local

Componentes da biblioteca padrão

1. initializer_list para contêineres
2. Mover semântica para contêineres
3. forward_list
4. Hash containers
   • unordered_map
   • unordered_multimap
   • unordered_set
   • unordered_multiset
5. Ponteiros de gerenciamento de recursos
   • unique_ptr
   • shared_ptr
   • weak_ptr
6. Suporte de simultaneidade
   • fio
   • mutexes
   • fechaduras
   • variáveis ​​de condição
7. Suporte de simultaneidade de nível superior
   • packaged_thread
   • futuro
   • promessa
   • assíncrono
8. tuplas
9. regex
10. Números aleatórios
    • uniform_int_distribution
    • distribuição normal
    • random_engine
    • etc.
11. Nomes de tipo inteiro, como int16_t, uint32_t e int_fast64_t
12. matriz
13. Copiando e repetindo exceções
14. erro no sistema
15. operações emplace () para contêineres
16. funções constexpr
17. Uso sistemático de funções noexcept
18. funcionar e ligar
19. Conversões de string para valor numérico
20. Alocadores com escopo definido
21. Traços de tipo
22. Utilitários de tempo: duração e time_point
23. Razão
24. quick_exit
25. Mais algoritmos, como move (), copy_if () e is_sorted ()
26. Coleta de lixo ABI
27. atômica

Recursos preteridos

1. Geração do construtor de cópias e a atribuição de cópias para uma classe com um destruidor.
2. Atribua uma string literal a um caractere *.
3. Especificação de exceção C ++ 98
   • inexcepted_handler
   • set_unexpected
   • get_unexpected
   • inesperado
4. Objetos de função e funções associadas
5. auto_ptr
6. registro
7. ++ em um bool
8. exportar
9. Moldes em estilo C