Когда мне действительно следует использовать noexcept?

Я думаю, что еще слишком рано давать ответ «передовой опыт» по этому поводу, так как не было достаточно времени, чтобы использовать его на практике. Если бы этот вопрос о спецификаторах броска спросили сразу после того, как они вышли, то ответы были бы совсем другими, чем сейчас.

Необходимость думать о том, нужно ли мне добавлять noexcept после каждого объявления функции, значительно снизила бы производительность программиста (и, честно говоря, была бы болью).

Что ж, тогда используйте его, когда очевидно, что функция никогда не выбросит.

Когда я могу реально ожидать улучшения производительности после использования noexcept? [...] Лично меня волнует noexcept из-за большей свободы, предоставляемой компилятору для безопасного применения определенных видов оптимизации.

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

Использование noexcept в большой четверке (конструкторы, присваивание, а не деструкторы, поскольку они уже noexcept), вероятно, приведет к лучшим улучшениям, поскольку noexcept проверки являются «обычными» в коде шаблона, например, в контейнерах std. Например, std::vector не будет использовать перемещение вашего класса, если он не отмечен noexcept (или компилятор может вывести его иначе).

Как я не перестаю повторять в последнее время: прежде всего семантика.

Добавление noexcept, noexcept(true) и noexcept(false) в первую очередь касается семантики. Это лишь вскользь обусловливает ряд возможных оптимизаций.

Как программист, читающий код, присутствие noexcept похоже на присутствие const: это помогает мне лучше понять, что может или не может произойти. Поэтому стоит потратить некоторое время на размышления о том, знаете ли вы, выдаст ли функция. Напоминаем, что любой тип распределения динамической памяти может вызывать ошибку.

Хорошо, теперь о возможных оптимизациях.

Наиболее очевидные оптимизации фактически выполняются в библиотеках. C ++ 11 предоставляет ряд свойств, которые позволяют узнать, является ли функция noexcept или нет, и сама реализация стандартной библиотеки будет использовать эти черты для поддержки noexcept операций над определяемыми пользователем объектами, которыми они манипулируют, если это возможно. Например, семантика перемещения.

Компилятор может только немного сэкономить (возможно) на данных обработки исключений, потому что он должен учесть тот факт, что вы могли солгать. Если функция, помеченная noexcept, выбрасывает, то вызывается std::terminate.

Эта семантика была выбрана по двум причинам:

• сразу же извлекает выгоду из noexcept, даже если зависимости его еще не используют (обратная совместимость)
• разрешение указания noexcept при вызове функций, которые теоретически могут вызывать, но не ожидаются для данных аргументов

Это действительно имеет (потенциально) огромное значение для оптимизатора компилятора. Компиляторы фактически обладали этой функцией в течение многих лет с помощью пустого оператора throw () после определения функции, а также с помощью расширений приличия. Я могу заверить вас, что современные компиляторы действительно используют эти знания для создания лучшего кода.

Почти каждая оптимизация в компиляторе использует что-то, называемое «потоковым графом» функции, чтобы понять, что является законным. Граф потока состоит из того, что обычно называют «блоками» функции (области кода, которые имеют один вход и один выход) и ребер между блоками, чтобы указать, куда поток может перейти. Noexcept изменяет диаграмму потока.

Вы просили конкретный пример. Рассмотрим этот код:

void foo(int x) {
    try {
        bar();
        x = 5;
        // Other stuff which doesn't modify x, but might throw
    } catch(...) {
        // Don't modify x
    }

    baz(x); // Or other statement using x
}

График потока для этой функции будет другим, если bar помечено noexcept (нет возможности для выполнения переходить между концом bar и оператором catch). Когда он помечен как noexcept, компилятор уверен, что значение x равно 5 во время функции baz - говорят, что блок x = 5 «доминирует» над блоком baz (x) без перехода от bar() к оператору catch.

Затем он может выполнять так называемое «постоянное распространение», чтобы сгенерировать более эффективный код. Здесь, если baz встроен, операторы, использующие x, могут также содержать константы, а затем то, что раньше было оценкой времени выполнения, может быть преобразовано в оценку времени компиляции и т. Д.

В любом случае, краткий ответ: noexcept позволяет компилятору генерировать более плотный потоковый граф, а потоковый граф используется для рассуждений обо всех видах общих оптимизаций компилятора. Для компилятора пользовательские аннотации такого рода прекрасны. Компилятор попытается выяснить это, но обычно не может (рассматриваемая функция может находиться в другом объектном файле, не видимом компилятору, или транзитивно использовать какую-то функцию, которая не видна), или когда это происходит, существует может возникнуть какое-то тривиальное исключение, о котором вы даже не подозреваете, поэтому оно не может неявно пометить его как noexcept (например, выделение памяти может вызвать bad_alloc).

noexcept может значительно улучшить производительность некоторых операций. Это происходит не на уровне генерации машинного кода компилятором, а путем выбора наиболее эффективного алгоритма: как уже упоминалось, вы делаете этот выбор с помощью функции std::move_if_noexcept. Например, рост std::vector (например, когда мы вызываем reserve) должен обеспечивать надежную гарантию безопасности исключений. Если он знает, что конструктор перемещения T не выполняет бросок, он может просто перемещать каждый элемент. В противном случае он должен скопировать все T. Это подробно описано в этом сообщении.

Когда я могу реально, кроме как наблюдать улучшение производительности после использования noexcept? В частности, приведите пример кода, для которого компилятор C ++ может генерировать лучший машинный код после добавления noexcept.

Эм, никогда? Никогда не бывает времени? Никогда.

noexcept предназначен для оптимизации производительности компилятора точно так же, как const предназначен для оптимизации производительности компилятора. То есть почти никогда.

noexcept в основном используется для того, чтобы «вы» могли определить во время компиляции, может ли функция вызвать исключение. Помните: большинство компиляторов не выдают специальный код для исключений, если он действительно что-то не генерирует. Итак, noexcept - это не просто подсказки компилятору о том, как оптимизировать функцию, а скорее подсказки вам о том, как использовать функцию.

Такие шаблоны, как move_if_noexcept, определят, определен ли конструктор перемещения с помощью noexcept, и вернут const& вместо && типа, если это не так. Это способ сказать, что нужно двигаться, если это очень безопасно.

В общем, вам следует использовать noexcept, если вы думаете, что это действительно будет полезно. Некоторый код будет использовать разные пути, если is_nothrow_constructible истинно для этого типа. Если вы используете код, который это делает, то не стесняйтесь noexcept подходящие конструкторы.

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

Выражаясь словами Бьярна (Язык программирования C ++, 4-е издание, стр. 366):

Если завершение является приемлемым ответом, это достигается неперехваченным исключением, поскольку оно превращается в вызов terminate () (§13.5.2.5). Кроме того, спецификатор noexcept (§13.5.1.1) может сделать это желание явным.

Успешные отказоустойчивые системы многоуровневые. Каждый уровень справляется с максимально возможным количеством ошибок, не слишком искажаясь, и оставляет все остальное на более высоких уровнях. Исключения поддерживают эту точку зрения. Кроме того, terminate() поддерживает это представление, предоставляя выход, если сам механизм обработки исключений поврежден или если он был использован не полностью, оставляя исключения неперехваченными. Точно так же noexcept обеспечивает простой выход для ошибок, восстановление которых кажется невозможным.

double compute(double x) noexcept;     {
    string s = "Courtney and Anya";
    vector<double> tmp(10);
    // ...
}

Конструктор вектора может не получить память для своих десяти двойников и выдать std::bad_alloc. В этом случае программа завершается. Он безоговорочно завершается вызовом std::terminate() (§30.4.1.3). Он не вызывает деструкторы из вызывающих функций. Это определяется реализацией, вызываются ли деструкторы из областей между throw и noexcept (например, for s в compute ()). Программа вот-вот завершится, поэтому мы в любом случае не должны зависеть от каких-либо объектов. Добавляя спецификатор noexcept, мы указываем, что наш код был написан не для того, чтобы справиться с выбросом.

1. Есть много примеров функций, которые, как я знаю, никогда не будут выбраны, но для которых компилятор не может определить это самостоятельно. Должен ли я добавлять noexcept к объявлению функции во всех таких случаях?

noexcept сложно, так как это часть интерфейса функций. В частности, если вы пишете библиотеку, ваш клиентский код может зависеть от свойства noexcept. Это может быть сложно изменить позже, так как вы можете сломать существующий код. Это может не вызывать беспокойства, если вы реализуете код, который используется только вашим приложением.

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

С другой стороны, если вы уверены, что функция никогда не должна бросать, и правильно, что она является частью спецификации, вы должны объявить ее noexcept. Однако имейте в виду, что компилятор не сможет обнаружить нарушения noexcept, если ваша реализация изменится.

2. В каких ситуациях я должен быть более осторожным с использованием noexcept, и в каких ситуациях я могу избежать подразумеваемого noexcept (false)?

Есть четыре класса функций, на которых вам следует сосредоточиться, потому что они, вероятно, будут иметь наибольшее влияние:

1. операции перемещения (оператор присваивания перемещения и конструкторы перемещения)
2. своп операции
3. средства освобождения памяти (оператор delete, оператор delete [])
4. деструкторы (хотя они неявно noexcept(true), если вы не сделаете их noexcept(false))

Эти функции обычно должны быть noexcept, и наиболее вероятно, что реализации библиотеки могут использовать свойство noexcept. Например, std::vector может использовать операции перемещения без метания без ущерба для строгих гарантий исключений. В противном случае придется вернуться к копированию элементов (как это было в C ++ 98).

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

3. Когда я могу реально ожидать улучшения производительности после использования noexcept? В частности, приведите пример кода, для которого компилятор C ++ может генерировать лучший машинный код после добавления noexcept.

Преимущество noexcept перед указанием отсутствия исключений или throw() состоит в том, что стандарт дает компиляторам больше свободы, когда дело доходит до раскрутки стека. Даже в случае throw() компилятор должен полностью раскрутить стек (и он должен делать это в точном обратном порядке построения объектов).

В случае noexcept, с другой стороны, этого делать не нужно. Нет необходимости раскручивать стек (но компилятору все равно разрешено это делать). Эта свобода позволяет дальнейшую оптимизацию кода, поскольку снижает накладные расходы, связанные с возможностью всегда раскручивать стек.

Связанный с этим вопрос о noexcept, разматывании стека и производительности содержит более подробную информацию о накладных расходах, когда требуется размотка стека.

Я также рекомендую книгу Скотта Мейерса «Эффективный современный C ++», «Правило 14: объявляйте функции без исключения, если они не будут генерировать исключения» для дальнейшего чтения.

Есть много примеров функций, которые, как я знаю, никогда не сработают, но для которых компилятор не может определить это самостоятельно. Должен ли я добавлять noexcept к объявлению функции во всех таких случаях?

Когда вы говорите: «Я знаю, что [они] никогда не выбросят», вы имеете в виду, исследуя реализацию функции, что вы знаете, что функция не выбросит. Я думаю, что этот подход вывернут наизнанку.

Лучше подумать, может ли функция генерировать исключения, чтобы быть частью дизайна функции: так же важно, как список аргументов и является ли метод мутатором (... const). Заявление о том, что «эта функция никогда не генерирует исключения», является ограничением реализации. Отсутствие этого не означает, что функция может генерировать исключения; это означает, что текущая версия функции и все будущие версии могут вызывать исключения. Это ограничение усложняет реализацию. Но некоторые методы должны иметь ограничение, чтобы быть практически полезными; самое главное, чтобы их можно было вызывать из деструкторов, а также для реализации кода «отката» в методах, которые обеспечивают строгую гарантию исключения.

Вот простой пример, чтобы проиллюстрировать, когда это действительно может иметь значение.

#include <iostream>
#include <vector>
using namespace std;
class A{
 public:
  A(int){cout << "A(int)" << endl;}
  A(const A&){cout << "A(const A&)" << endl;}
  A(const A&&) noexcept {cout << "A(const A&&)" << endl;}
  ~A(){cout << "~S()" << endl;}
};
int main() {
  vector<A> a;
  cout << a.capacity() << endl;
  a.emplace_back(1);
  cout << a.capacity() << endl;
  a.emplace_back(2);
  cout << a.capacity() << endl;
  return 0;
}

Вот результат

0
A(int)
1
A(int)
A(const A&&)
~S()
2
~S()
~S()

Если мы удалим noexcept в конструкторе перемещения, вот результат

0
A(int)
1
A(int)
A(const A&)
~S()
2
~S()
~S()

Ключевое отличие - A(const A&&) против A(const A&&). Во втором случае он должен скопировать все значения с помощью конструктора копирования. ОЧЕНЬ НЕЭФФЕКТИВНО !!