В минусе исключения из C++

Question

Я читал руководство по стилю Google C++ и запутался в части Exceptions. Один из недостатков его использования, согласно руководству, заключается в следующем:

Безопасность исключений требует как RAII , так и различных методов кодирования. Лот вспомогательных механизмов необходим для make writing correct exception-safe код легкий. Кроме того, чтобы избежать необходимости считывать читателей, чтобы понять весь график звонка , код, защищенный от ошибок, должен изолировать логику, которая записывает в постоянное состояние в фазу «фиксации» . Это будет иметь как преимущества , так и затраты (возможно, если вы вынуждены , чтобы сфотографировать код, чтобы изолировать фиксацию ). Позволяя исключения будут заставить нас всегда платить эти расходы даже тогда, когда они не стоят

В частности, утверждение, что я не понимаю, это:

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

и это:

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

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

Answer 1

«пишет постоянное состояние» означает, грубо «пишет в файл» или "записывает в базу данных ».

«в фазу« совершить ».« означает примерно „Делая все письма сразу“

„ может быть, где вы вынуждены запутать код, чтобы изолировать фиксации“ означает примерно» Это может сделать код трудно читать "(Незначительное злоупотребление словом «obfuscate», что означает намеренно сделать что-то трудное для чтения, в то время как здесь они означают, что это затрудняет чтение, но это злоупотребление могло быть преднамеренным, для драматического эффекта).

Разработка более: «пишет к постоянному состоянию "более тесно означает" Выписать, некоторым постоянным СМИ, все подробности об этом объекте, которые понадобятся для r выровняйте его ». Если запись была прервана исключением, тогда эти «выписанные детали» (т. Е. «Постоянное состояние») могут содержать половину нового состояния и половину старого состояния, что приводит к недопустимому объекту при его воссоздании. Следовательно, запись состояния должно выполняться как одно непрерывное действие.

Answer 2

В основном, современный C++ использует управление ресурсами с ограниченным диапазоном (SBRM или RAII). То есть, объект очищает ресурс в своем деструкторе, который, как гарантируется, будет вызван.

Все это прекрасно и денди, если ваш код не является современным. Например:

int *i = new int(); 
do_something(i); 
delete i; 

Если do_something бросает исключение, вы просочились. Правильное решение не иметь ресурс в дикой природе, как это, т.е .:

std::auto_ptr<int> i(new int()); 
do_something(i.get()); 

Теперь она никогда не может течь (и код чище!).

Я думаю, что руководство пытается сказать, что у нас уже есть весь этот старый код, и использование современного стиля потребует слишком много усилий. Поэтому давайте не будем использовать исключения. (Вместо того, чтобы исправить весь код ... Я не люблю Руководство Стиля Google очень много.)

Answer 3

Что это говорит о постоянном состоянии, это: даже если вы используете RAII, и ваш объект будет разрушен должным образом, что позволит вам очистить, если код в блоке try каким-то образом изменил состояние системы, вам, скорее всего, придется выяснить, как отменить эти изменения, потому что операция не завершилась успешно. Они используют термин «фиксация» здесь, когда речь идет о транзакциях, о том, что при выполнении операции состояние системы должно быть таким, как если бы оно было завершено на 100% успешно или вообще не произошло.

Вот как это может получить перепутано даже с RAII:

struct MyClass 
{ 
    MyClass(Foo* foo) 
    { 
     m_bar = new Bar; 
     foo->changeSomeState(); 
    } 

    ~MyClass() 
    { 
     delete m_bar; 
    } 

    Bar* m_bar; 
}; 

Теперь, если у вас есть этот код:

try 
{ 
    MyClass myClass(foo); 
    Baz baz; 
    baz.doSomething(); // Throws an exception 
} 
catch(...) 
{ 
    // MyClass doesn't leak memory, but should it try to undo 
    // the change it made to foo? 
} 

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

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

Answer 4

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

• Joel on Software - 13 - Exceptions
• Joel on Software - Making Wrong code look Wrong
• The Old New Thing - Cleaner, more elegant, and harder to recognize

Мой любимый пример: если вы используете исключения, этот код, скорее всего, ошибочен - и его невозможно сказать, просто взглянув на него:

void SomeMethod(){ 
    m_i++; 
    SomeOtherMethod(); 
    m_j++; 
} 

Answer 5

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

Я удивлен тем, что в эту линию не попало больше людей. Это обсуждается «con»: обработка исключений является дорогостоящей. Остальная часть параграфа - это только детали того, почему требуется столько машин.

Это недостаток исключений, которые обычно игнорируются на двухъядерных 2 ГГц машинах с 4 ГБ ОЗУ, 1 ТБ жестким диском и кусками виртуальной памяти для каждого процесса. Если код легче понять, отладить и написать, затем купить/сделать быстрее аппаратное обеспечение и написать узкие места без исключений, а также в C.

Однако в системе с более жесткими ограничениями вы не можете игнорировать накладные расходы. Попробуй это. Сделайте файл test.cpp следующим образом:

//#define USE_EXCEPTIONS 
int main() { 
    int value; 
#ifdef USE_EXCEPTIONS 
    try { 
#endif 
    value++; 
#ifdef USE_EXCEPTIONS 
    if (value != 1) { 
     throw -1; 
    } 
    } 
    catch (int i) { 
     return i; 
    } 
#else 
     return -1; 
} 
#endif 

    return value; 
} 

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

Скомпилируйте его в любом случае с
g++ -S -nostdlib test.cpp
и посмотрите на полученный файл сборки test.s. Шахта имела длину 29 строк без блока if (value != 1) { return -1 }, или 37 строк с примером тестового блока возврата. Большая часть из них была ярлыками для компоновщика.

После того как вы удовлетворены этим кодом, раскомментируйте опцию #define USE_EXCEPTIONS в верхней части страницы и скомпилируйте ее снова. Wham! 155 строк кода для обработки исключения. Я дам вам, что теперь у нас есть дополнительный оператор return и конструкция if, но это всего лишь пара строк.

Это далеко не полный контрольный показатель обработки исключений. Для более авторитетного и тщательного ответа см. Раздел 5.4 ISO/IEC TR18015 Technical Report on C++ Performance. Обратите внимание, что они начинают с почти-как-тривиальным примером:

double f1(int a) { return 1.0/a; } 
double f2(int a) { return 2.0/a; } 
double f3(int a) { return 3.0/a; } 
double g(int x, int y, int z) { 
    return f1(x) + f2(y) + f3(z); 
} 

так что есть смысл в использовании абсурдно небольшие тестовые случаев. Существуют также потоки StackOverflow here и here (где я снял вышеуказанную ссылку, любезно предоставил Ксавье Нодет).

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