Что мешает оптимизации компилятора переупорядочить сильно исключающий код код?

Question

В случае строгого исключения кода Йона Калба для решения примера Cargill Widget, что мешает компилятору переорганизовать операции и, таким образом, сделать код не очень безопасным для исключений?

#include <algorithm> // std::swap 

template< typename T1, typename T2 > 
class Cargill_Widget 
{ 
public: 
    Cargill_Widget& operator=(Cargill_Widget const& r_other) 
    { 
     using std::swap; 

     T1 temp_t1(r_other.m_t1); // may throw 
     T2 temp_t2(r_other.m_t2); // may throw 
     /* The strong exception-safety line */ 
     swap(m_t1, temp_t1); // no throw 
     swap(m_t2, temp_t2); // no throw 

     return *this; 
    } 

private: 
    T1 m_t1; 
    T2 m_t2; 
}; 

ли это «компилятор не может изменить наблюдаемое поведение» правила?

Ссылка:

• Джон KALB в "Exception-Safe Code" Презентация Слайды: http://www.exceptionsafecode.com/slides/esc.pdf

Answer 1

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

Answer 2

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