standard - c++ wikipedia en




Quais alterações significativas são introduzidas no C++ 11? (7)

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

Existem outras alterações de quebra?


Características da linguagem

  1. Inicialização uniforme e geral 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 Variadic
  14. Aliases de tipo e modelo
  15. Caracteres Unicode
  16. tipo inteiro longo longo
  17. alinhar e alinhar
  18. decl.
  19. Literais de string brutos
  20. POD generalizado
  21. Uniões generalizadas
  22. Classes locais como argumentos de modelo
  23. Sintaxe do tipo de retorno de sufixo
  24. [[carries_dependency]] e [[noreturn]]
  25. noexcept specifier
  26. noexcept operador.
  27. Recursos do C99:
    • tipos integrais estendidos
    • concatenação de corda estreita / larga
    • _ _ STDC_HOSTED _ _
    • _Pragma (X)
    • vararg macros e argumentos de macro vazios
  28. _ _ func _ _
  29. Namespaces inline
  30. Delegando construtores
  31. Inicializadores de membros em classe
  32. padrão e excluir
  33. Operadores explícitos de conversão
  34. Literais definidos pelo usuário
  35. Modelos externos
  36. Argumentos de modelo padrão para modelos de função
  37. Herdando construtores
  38. substituir e final
  39. Regra mais simples e mais geral do SFINAE
  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. Recipientes de Hash
    • unordered_map
    • unordered_multimap
    • unordered_set
    • unordered_multiset
  5. Ponteiros de gerenciamento de recursos
    • unique_ptr
    • shared_ptr
    • weak_ptr
  6. Suporte de Concorrência
    • fio
    • mutexes
    • fechaduras
    • variáveis ​​de condição
  7. Suporte de simultaneidade de nível mais alto
    • 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 recriando exceções
  14. erro no sistema
  15. operações emplace () para contêineres
  16. funções constexpr
  17. Uso sistemático de funções sem exceções
  18. função e ligar
  19. String para conversões de valor numérico
  20. Alocadores com escopo
  21. Digite traços
  22. Utilitários de hora: duration e time_point
  23. relação
  24. quick_exit
  25. Mais algoritmos, como move (), copy_if () e is_sorted ()
  26. Coleta de lixo ABI
  27. atómicos

Recursos descontinuados

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

A falha de extração de fluxo é tratada de forma 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 chars foi acumulada no estágio 2 que é convertido (de acordo com as regras do scanf ) em um valor do tipo de val . Este valor é armazenado em val e ios_base::goodbit é armazenado em err .
  • A sequência de caracteres acumulados no estágio 2 faria com que o scanf uma falha de entrada. ios_base::failbit é atribuído a err . [ed: Nada é armazenado em 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 não conseguir converter todo o campo . ios_base::failbit é atribuído a err .
  • o valor representável mais positivo, se o campo representar um valor muito grande positivo para ser representado em val . ios_base::failbit é atribuído a err .
  • o valor representável mais negativo ou zero para um tipo inteiro sem sinal, se o campo representar um valor muito grande negativo para ser representado em val . ios_base::failbit é atribuído a err .
  • o valor convertido, caso contrário.

O valor numérico resultante é armazenado em val .

Implementações

  • GCC 4.8 saídas corretamente para C ++ 11 :

    Asserção `x == -1 'falhou

  • GCC 4.5-4.8 todas as saídas para C ++ 03 são as seguintes, o que parece ser um erro:

    Asserção `x == -1 'falhou

  • Visual C ++ 2008 Express corretamente saídas para C ++ 03:

    Falha na declaração: x == 0

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

    Falha na declaração: x == 0



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. Eu adicionei alguns exemplos para ilustrar as diferenças.

Existem algumas incompatibilidades relacionadas à biblioteca onde eu não sei exatamente as implicações, então deixo as outras para serem elaboradas.

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

Determinados literais inteiros maiores do que podem ser representados por muito tempo podem mudar de um tipo inteiro sem sinal para um longo tempo assinado.

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

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

Código C ++ 2003 válido que usa a palavra auto chave auto como um especificador de classe de armazenamento pode ser inválido em C ++ 0x.

A redução de conversões causa incompatibilidades com o C ++ 03. Por exemplo, o código a seguir é válido em C ++ 2003, mas é inválido neste Padrão Internacional porque o dobro para int é uma conversão de restrição:

int x[] = { 2.0 };

Funções de membro especiais declaradas implicitamente são definidas como excluídas quando a definição implícita teria sido mal formada.

Um programa C ++ 2003 válido que usa uma dessas funções de 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) torna-se malformado.

Exemplo por mim:

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

Tal tamanho de truques tem sido usado por alguns SFINAE, e precisa ser mudado agora :)

Destruidores declarados pelo usuário possuem uma especificação de exceção implícita.

Exemplo por mim:

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

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

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

Uma declaração válida do C ++ 2003 que contém a export está mal formada em C ++ 0x.

Uma expressão C ++ 2003 válida contendo > seguida imediatamente por outro > agora pode ser tratada como fechar dois modelos.

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

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

Em C ++ 03, isso chama f(long) , mas em C ++ 0x, isso chama f(int) . Deve-se notar que tanto no C ++ 03 quanto no C ++ 0x, as seguintes chamadas f(B) (o contexto de instanciação ainda considera apenas as 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 é tomada, porque não tem ligação externa.

Mudanças de biblioteca

Código C ++ 2003 válido que usa quaisquer identificadores adicionados à biblioteca padrão C ++ de C ++ 0x pode falhar ao compilar ou produzir resultados diferentes neste padrão internacional.

Código C ++ 2003 válido que #includes cabeçalhos com nomes de novos cabeçalhos de biblioteca padrão C ++ 0x pode ser inválido neste padrão internacional.

Código C ++ 2003 válido que foi compilado esperando que a troca esteja em <algorithm> pode ter que incluir <utility>

O espaço de nomes global posix está agora reservado para padronização.

O código C ++ 2003 válido que define override macros override , final , carries_dependency ou noreturn as macros é inválido em C ++ 0x.


Quebrando a mudança?

Bem, por um lado, se você usou decltype , constexpr , nullptr , etc. como identificadores, então você pode estar em apuros ...



struct x {
   x(int) {}
};

void f(auto x = 3) { }

int main() {
   f();
}

C ++ 03: válido.

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







c++11