Какие идиомы C ++ устарели в C ++ 11?

С новым стандартом появляются новые способы ведения дел, и многие из них более хороши, чем старые, но старый способ все еще в порядке. Также ясно, что новый стандарт официально не очень устарел по причинам обратной совместимости. Итак, вопрос, который остается:

Какие старые способы кодирования определенно уступают стилям C ++ 11, и что мы можем теперь вместо этого делать?

Отвечая на это, вы можете пропустить очевидные вещи, такие как «использовать автоматические переменные».

1. Финальный класс : C ++ 11 предоставляет finalспецификатор для предотвращения деривации класса
2. Лямбда C ++ 11 существенно снижает потребность в классах именованных объектов функций (функторов).
3. Move Constructor : Волшебные способы, которыми std::auto_ptrработы больше не нужны из-за первоклассной поддержки ссылок на rvalue.
4. Safe Bool : это было упомянуто ранее. Явные операторы C ++ 11 устраняют эту очень распространенную идиому C ++ 03.
5. Сжатие до соответствия : многие контейнеры C ++ 11 STL предоставляют функцию- shrink_to_fit()член, которая должна исключить необходимость замены на временную.
6. Временный базовый класс : некоторые старые библиотеки C ++ используют эту довольно сложную идиому. С семантикой перемещения она больше не нужна.
7. Тип Safe Enum перечисления очень безопасны в C ++ 11.
8. Запрещение выделения кучи := delete Синтаксис - это гораздо более прямой способ сказать, что определенная функциональность явно запрещена. Это применимо для предотвращения выделения кучи (т.е. =deleteдля члена operator new), предотвращения копирования, назначения и т. Д.
9. Шаблонный typedef : шаблоны псевдонимов в C ++ 11 уменьшают потребность в простых шаблонных определениях типов. Тем не менее, генераторы сложных типов все еще нуждаются в мета-функциях.
10. Некоторые численные вычисления во время компиляции, такие как Фибоначчи, можно легко заменить, используя обобщенных константных выражений
11. result_of: Использование шаблона класса result_ofдолжно быть заменено на decltype. думаюresult_of использует, decltypeкогда это доступно.
12. Инициализаторы членов класса сохраняют типизацию для инициализации по умолчанию нестатических членов со значениями по умолчанию.
13. В новом C ++ 11 код NULLдолжен быть переопределен как nullptr, но см. Доклад STL чтобы узнать, почему они решили отказаться от него.
14. Фанатики шаблонов выражений рады иметь конечный тип возврата в C ++ 11 синтаксис функции . Не более 30 строк возврата!

Я думаю, что я остановлюсь там!

В какой-то момент утверждалось, что нужно возвращать по constзначению, а не просто по значению:

const A foo();
^^^^^

Это было в основном безвредно в C ++ 98/03 и, возможно, даже обнаружило несколько ошибок, которые выглядели так:

foo() = a;

Но возврат constв C ++ 11 противопоказан, потому что он запрещает семантику перемещения:

A a = foo();  // foo will copy into a instead of move into it

Так что просто расслабьтесь и код:

A foo();  // return by non-const value

Как только вы можете отказаться 0и NULLв пользуnullptr , сделайте это!

В неуниверсальном коде использование 0или NULLне такое уж большое дело. Но как только вы начинаете передавать константы нулевого указателя в универсальном коде, ситуация быстро меняется. При переходе 0к a template<class T> func(T) Tвыводится как intконстанта нулевого указателя, а не как. И после этого он не может быть преобразован обратно в константу нулевого указателя. Это переходит в болото проблем, которых просто не существует, если использовать только вселенную nullptr.

C ++ 11 не считается устаревшим 0и NULLявляется константой нулевого указателя. Но вы должны кодировать, как если бы это было.

Безопасный бул идиома →explicit operator bool() .

Конструкторы частных копий (boost :: noncopyable) → X(const X&) = delete

Имитация финального класса с частным деструктором и виртуальным наследованием →class X final

Одна из вещей, которая просто заставляет вас избегать написания базовых алгоритмов на C ++ 11, - это доступность лямбд в сочетании с алгоритмами, предоставляемыми стандартной библиотекой.

Я использую их сейчас, и невероятно, как часто вы просто говорите, что вы хотите сделать, используя count_if (), for_each () или другие алгоритмы вместо того, чтобы снова писать чертовы циклы.

Как только вы используете компилятор C ++ 11 с полной стандартной библиотекой C ++ 11, у вас больше нет веских оправданий, чтобы не использовать стандартные алгоритмы для построения своих . Лямбда просто убей это.

Зачем?

На практике (после того, как я сам использовал этот способ написания алгоритмов), гораздо проще читать что-то, построенное с простыми словами, означающими то, что сделано, чем с некоторыми циклами, которые вы должны расшифровать, чтобы узнать значение. Тем не менее, автоматическое определение лямбда-аргументов очень поможет сделать синтаксис более простым для сравнения с необработанным циклом.

По сути, алгоритмы чтения, сделанные с помощью стандартных алгоритмов, намного проще, чем слова, скрывающие детали реализации циклов.

Я предполагаю, что теперь нужно думать только об алгоритмах более высокого уровня, поскольку у нас есть алгоритмы более низкого уровня, на которых можно основываться.

Вам нужно будет реализовывать пользовательские версии swapреже. В C ++ 03 swapчасто необходим эффективный отказ от передачи , чтобы избежать дорогостоящих и бросающих копий, и, поскольку std::swapиспользуются две копии, swapчасто приходится настраивать их. В C ++ std::swapиспользует move, и поэтому фокус смещается на реализацию эффективных и не вызывающих бросков конструкторов перемещения и операторов присваивания перемещения. Поскольку для них по умолчанию часто просто отлично, это будет гораздо меньше работы, чем в C ++ 03.

Как правило, трудно предсказать, какие идиомы будут использоваться, так как они созданы на основе опыта. Мы можем ожидать «Эффективный C ++ 11», возможно, в следующем году, и «Стандарты кодирования C ++ 11» только через три года, потому что необходимого опыта еще нет.

Я не знаю его имени, но код C ++ 03 часто использовал следующую конструкцию в качестве замены отсутствующего назначения перемещения:

std::map<Big, Bigger> createBigMap(); // returns by value

void example ()
{
  std::map<Big, Bigger> map;

  // ... some code using map

  createBigMap().swap(map);  // cheap swap
}

Это позволило избежать копирования благодаря исключению копирования в сочетании с swapвышеизложенным.

Когда я заметил, что компилятор, использующий стандарт C ++ 11, больше не нарушает следующий код:

std::vector<std::vector<int>> a;

для якобы содержащего оператора >> я начал танцевать. В более ранних версиях нужно было бы сделать

std::vector<std::vector<int> > a;

Что еще хуже, если вам когда-либо приходилось отлаживать это, вы знаете, насколько ужасны сообщения об ошибках, которые появляются из-за этого.

Я, однако, не знаю, было ли это "очевидным" для вас.

Возврат по значению больше не проблема. С семантикой перемещения и / или оптимизацией возвращаемого значения (зависит от компилятора) функции кодирования более естественны без затрат и затрат (большую часть времени).