Які переломні зміни вводяться в C ++ 11?

Я знаю, що принаймні одна зі змін C ++ 11, яка призведе до припинення компіляції старого коду: введення explicit operator bool()в стандартну бібліотеку, заміна старих екземплярів operator void*(). Зрозуміло, що код, який буде порушено, - це, мабуть, код, який у першу чергу не мав би бути дійсним, але все-таки все-таки є переломною зміною: програми, які раніше були дійсними, більше не є.

Чи є якісь інші зміни?

У FDIS є розділ щодо несумісності у додатку C.2"C ++ та ISO C ++ 2003".

Короткий підсумок, перефразовуючи FDIS тут, щоб зробити його (кращим) придатним як відповідь ТА. Я додав кілька власних прикладів, щоб проілюструвати відмінності.

Є кілька несумісностей, пов’язаних з бібліотекою, де я точно не знаю наслідків, тому я залишаю їх іншим детальніше.

Основна мова

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

Нові ключові слова: alignas, alignof, char16_t, char32_t, constexpr, decltype, noexcept, nullptr, static_assert та thread_local

Деякі цілі літерали, більші, ніж можуть бути представлені довгими, можуть змінюватися від непідписаного цілого числа до довгого підписаного.

Дійсний код C ++ 2003, який використовує ціле ділення, округляє результат до 0 або до негативної нескінченності, тоді як C ++ 0x завжди округляє результат до 0.

(правда, це не є проблемою сумісності для більшості людей).

Дійсний код C ++ 2003, який використовує ключове слово autoяк специфікатор класу зберігання, може бути недійсним у C ++ 0x.

Звуження конверсій спричиняє несумісність із C ++ 03. Наприклад, наступний код дійсний у C ++ 2003, але недійсний у цьому Міжнародному стандарті, оскільки подвійний до int - це конверсія звуження:

int x[] = { 2.0 };

Неявно оголошені функції спеціальних членів визначаються як видалені, коли неявне визначення було б неправильно сформовано.

Дійсна програма C ++ 2003, яка використовує одну з цих функцій спеціального члена в контексті, коли визначення не потрібно (наприклад, у виразі, який потенційно не оцінюється) стає неправильним.

Приклад мною:

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

Такі хитрощі розмірів використовувались у деяких SFINAE, і їх потрібно змінити зараз :)

Задекларовані користувачем деструктори мають неявну специфікацію винятків.

Приклад мною:

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

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

Цей код дзвонить terminateу C ++ 0x, але не в C ++ 03. Тому що неявна специфікація виключень A::~Aу C ++ 0x є noexcept(true).

Дійсна декларація C ++ 2003, що містить exportнеправильну форму в C ++ 0x.

Дійсний вираз C ++ 2003, що містить >негайно інший, >тепер може трактуватися як закриття двох шаблонів.

У C ++ 03 >>завжди буде маркер оператора shift.

Дозволити залежні виклики функцій із внутрішнім зв’язком.

Приклад мною:

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

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

int main() { g(0); }

У C ++ 03 це дзвінки f(long), а у C ++ 0x - це дзвінки f(int). Слід зазначити, що і в C ++ 03, і ​​в C ++ 0x є наступні виклики f(B)(контекст інстанції все ще враховує лише декларації зовнішніх зв'язків).

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)не приймається, оскільки вона не має зовнішніх зв'язків.

Зміни бібліотеки

Дійсний код C ++ 2003, який використовує будь-які ідентифікатори, додані до стандартної бібліотеки C ++ C ++ 0x, може не вдатися до компіляції або отримання різних результатів у цьому міжнародному стандарті.

Дійсний код C ++ 2003, що #includesзаголовки з іменами нових стандартних заголовків бібліотек C ++ 0x можуть бути недійсними в цьому Міжнародному стандарті.

Дійсний код C ++ 2003, який був складений, очікуючи на заміну, <algorithm>може замість цього включити<utility>

Глобальний простір імен posixтепер зарезервований для стандартизації.

Дійсний C ++ 2003 код , який визначає override, final, carries_dependencyабо noreturnяк макроси неприпустимий в C ++ 0x.

Змінилося значення ключового слова авто.

Порушення змін?

Ну, у - перших, якщо ви використовували decltype, constexpr, nullptrі т.д. в якості ідентифікаторів , то ви можете бути в біді ...

Деякі основні несумісності, які не охоплені розділом несумісності:

C ++ 0x розглядає ім'я введеного класу як шаблон, якщо ім'я передається як аргумент параметру шаблону шаблону, і як тип, якщо він передається параметру типу шаблону.

Дійсний код C ++ 03 може поводитись по-різному, якщо він покладається на введене ім'я класу, щоб завжди бути типом у цих сценаріях. Приклад коду, взятого з мого піару

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

У C ++ 03 код викликає другий gобидва рази.

C ++ 0x робить деякі імена, від яких залежав C ++ 03, тепер не залежними. І вимагає пошук імен для незалежних кваліфікованих імен, які посилаються на членів шаблону поточного класу, щоб бути повтореним при створенні ініціативи, і вимагає перевірити, чи шукають ці імена так само, як це робиться в контексті визначення шаблону.

Дійсний код C ++ 03, який залежить від правила домінування, тепер може більше не компілюватися через цю зміну.

Приклад:

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

Цей дійсний код C ++ 03, який викликає A<int>::f, не є дійсним у C ++ 0x, тому що пошук імен при інстанціюванні знайдеться A<int>::fна відміну від B::f, викликаючи конфлікт із пошуком при визначенні.

На даний момент не зрозуміло, чи є дефектом FDIS. Комітет знає про це і оцінить ситуацію.

Декларація, що використовує, де остання частина є такою ж, як ідентифікатор в останній частині класифікатора у кваліфікованому імені, що позначає базовий клас, та, використовуючи оголошення, тепер називає конструктор замість членів з цим ім'ям.

Приклад:

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

Наведений вище приклад код добре сформований у C ++ 03, але неправильно сформований у C ++ 0x, як A::Bце ще недоступно в main.

Провал вилучення потоку трактується по-різному.

Приклад

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

Змінити пропозицію

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

Стандартна довідка

[C++03: 22.2.2.1.2/11]: Результатом обробки 2 стадії може бути один із

• На етапі 2 накопичена послідовність знаків, яка перетворюється (згідно з правилами scanf) у значення типу val. Це значення зберігається valі ios_base::goodbitзберігається в err.
• Послідовність символів, накопичена на етапі 2, призвела б scanfдо повідомлення про помилку введення. ios_base::failbitпризначено err. [ред .: Нічого не зберігається val.]

[C++11: 22.4.2.1.2/3]: [..] Числове значення, яке потрібно зберегти, може бути одним із:

• нуль, якщо функція перетворення не в змозі перетворити все поле . ios_base::failbitпризначено err.
• найпозитивніше репрезентабельне значення, якщо поле представляє величину, занадто велику позитивну, щоб бути представленою в val. ios_base::failbitпризначено err.
• найбільш негативне представлене значення або нуль для непідписаного цілого типу, якщо поле представляє значення, занадто велике негатив, щоб бути представленим в val. ios_base::failbitпризначено err.
• перетворене значення, інакше.

Отримане числове значення зберігається в val.

Впровадження

• GCC 4.8 правильно виводить для C ++ 11 :

  Ствердження `x == -1 'не вдалося

• GCC 4.5-4.8 весь вихід для C ++ 03 наступне, що, здається, буде помилкою:

  Ствердження `x == -1 'не вдалося

• Візуально виводить Visual C ++ 2008 Express для C ++ 03:

  Твердження не вдалося: x == 0

• Невірно виводиться Visual C ++ 2012 Express для C ++ 11, що, як видається, є проблемою стану реалізації:

  Твердження не вдалося: x == 0

Яким чином введення явних операторів перетворення є суттєвою зміною? Стара версія як і раніше буде настільки ж «дійсною», як і раніше.

Так, перехід від operator void*() constна explicit operator bool() constстане переломною, але лише в тому випадку, якщо він буде використаний таким чином, який не так у собі та поза ним. Відповідний код не буде порушений.

Тепер, ще одна головна зміна - заборона звуження конверсій під час сукупної ініціалізації :

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

Редагувати : пам'ятаючу пам'ять, std::identity<T>буде видалено в C ++ 0x (див. Примітку). Це зручність структури, щоб зробити типи залежними. Оскільки структура дійсно не робить багато, це має виправити:

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

У бібліотеці контейнерів є численні зміни, які дозволяють більш ефективно використовувати код, але мовчазно порушують сумісність на кілька випадків.

Розглянемо, наприклад, std::vectorконструкцію за замовчуванням, C ++ 0x та порушення змін .

Було багато дискусій щодо неявного руху, що порушує сумісність

( старша сторінка з відповідною дискусією )

Якщо ви читаєте в коментарях, неявна повернення ходу також є суттєвою зміною.

struct x {
   x(int) {}
};

void f(auto x = 3) { }

int main() {
   f();
}

C ++ 03: дійсне.

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

Мовні особливості

1. Уніфікована і загальна ініціалізація за допомогою {}
2. авто
3. Попередження звуження
4. constexpr
5. Діапазон на основі циклу
6. nullptr
7. перерахунок класу
8. static_assert
9. std :: inicijalizer_list
10. Оцінки посилань (семантика переміщення)
11. >>
12. Лямбда
13. Варіанти шаблонів
14. Псевдоніми типу та шаблону
15. Символи Unicode
16. довгий довгий цілий тип
17. алігнас і алігноф
18. decltype
19. Сирі літеральні рядки
20. Узагальнений ПОД
21. Узагальнені союзи
22. Локальні класи як аргументи шаблону
23. Синтаксис повернення суфікса
24. [[несе_залежність]] і [[неретурн]]
25. noexcept специфікатор
26. noexcept оператора.
27. Особливості C99:
    • розширені інтегральні типи
    • конкатенація вузької / широкої струни
    • _ _ STDC_HOSTED _ _
    • _Прагма (X)
    • vararg макроси та порожні макроаргументи
28. _ _ func _ _
29. Вбудовані простори імен
30. Делегуючі конструктори
31. Ініціалізатори учасників класу
32. за замовчуванням та видалити
33. Явні оператори перетворення
34. Визначені користувачем літерали
35. Зовнішні шаблони
36. Аргументи шаблону за замовчуванням для шаблонів функцій
37. Наслідування конструкторів
38. переосмислення та остаточне
39. Простіше і більш загальне правило SFINAE
40. Модель пам'яті
41. нитка_локальна

Компоненти стандартної бібліотеки

1. inicijalizer_list для контейнерів
2. Перемістіть семантику для контейнерів
3. вперед_ список
4. Хеш-контейнери
   • unordered_map
   • unordered_multimap
   • unorряд_set
   • unordered_multiset
5. Показники управління ресурсами
   • unique_ptr
   • shared_ptr
   • слабкий_птр
6. Підтримка одночасності
   • нитка
   • мутекси
   • замки
   • змінні умови
7. Підтримка одночасності вищого рівня
   • Packaged_thread
   • майбутнє
   • обіцянка
   • асинхронізація
8. кортежі
9. регекс
10. Випадкові числа
    • рівномірний_розподіл
    • нормальний_розподіл
    • random_engine
    • тощо.
11. Імена типу цілого числа, такі як int16_t, uint32_t та int_fast64_t
12. масив
13. Копіювання та повторне скидання винятків
14. системна помилка
15. операції emplace () для контейнерів
16. функції constexpr
17. Систематичне використання функцій без винятку
18. функціонувати і зв’язувати
19. Рядок перетворення числових значень
20. Діапазони розподільників
21. Тип ознак
22. Утиліти часу: тривалість і час_точки
23. співвідношення
24. quick_exit
25. Більше алгоритмів, таких як move (), copy_if () та is_sorted ()
26. Збір сміття ABI
27. атома

Застарілі функції

1. Генерація конструктора копій та призначення копії для класу з деструктором.
2. Призначте рядковий літерал до символу *.
3. C ++ 98 специфікація винятків
   • Uncepted_handler
   • set_unexpected
   • get_unexpected
   • несподіваний
4. Об'єкти функцій та пов'язані з ними функції
5. auto_ptr
6. реєструвати
7. ++ на bool
8. експорт
9. Касти в стилі C