Всегда ли обнуляется указатель?

[Sheogorath]

Здравствуйте!

Есть такой код:

int *pVal;
try
{
pVal = nullptr;
pVal = new int;
}
catch (bad_alloc &ba)
{
delete pVal;
cout << ba.what();
}

Вопрос состоит в следующем: всегда ли будет обнуляться указатель pVal перед вызовом операции new?. То есть, может ли компилятор оптимизировать код (возможно при каких-то особых настройках оптимизации) таким образом, что перед попыткой выделения памяти операцией new не произойдёт обнуление указателя?

[p51x]

Я бы даже сказал, что в большинстве случаев данный код выкинется. Т.к. старое значение не используется и сразу перезатирается.

[Sheogorath]

Хм, операция new может сгенерировать исключение. В этом случае переменная pVal не будет перезатёрта, а значит, если компилятор выкинет инициализацию нулём, то pVal будет содержать случайное значение. Следовательно попытка вызова delete в блоке catch может закончиться очень плохо ((

Таким образом, возможна ситуация, когда старое значение не перезатирается и используется. Компилятор это не учтёт и всё равно выкинет обнуление переменной??

[p51x]

Вы в катч попадаете, если у нью все плохо. Зачем там делит делать?

[Sheogorath]

Да, Вы правы, в данном конкретном случае delete внутри catch не нужен. Я написал его там просто для примера. Дело не в delete, дело в том, что старое значение переменной, которое, якобы не используется и будет выкинуто компилятором, на самом деле использоваться может.
Если компилятор не выбросит инициализацию указателя нулём, то вызов delete в блоке catch будет безопасен, а если выбросит, то delete будет применяться к неинициализированному указателю. Неужели компилятор это не учитывает?

[Son Of Pain]

Компилятор может оптимизировать как угодно до тех пор, пока не меняется наблюдаемое поведение программы (as-if rule). У этого правила есть только пара исключений - компилятор может убирать некоторые вызовы конструктора копирования (copy elision), и некоторые выделения памяти (начиная с С++14).

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

Следовательно, компилятор может убрать присваивание тогда и только тогда, когда он на 100% гарантирует, что вызов new не бросит эксепшн. Тобишь в реальной жизни практически никогда.

[Croessmah]

Сообщение от Son Of Pain

Компилятор может оптимизировать как угодно

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

[p51x]

Следовательно, компилятор может убрать присваивание тогда и только тогда, когда он на 100% гарантирует, что вызов new не бросит эксепшн. Тобишь в реальной жизни практически никогда.

Включите оптмизацию и из try присваивание пропадет... другое дело, что компилятор заметит delete и перенесет присваивание в catch.

[Croessmah]

Сообщение от p51x

Включите оптмизацию и из try присваивание пропадет... другое дело, что компилятор заметит delete и перенесет присваивание в catch.

В коде ТС неизвестен контекст, поэтому однозначно сказать сможет ли компилятор оптимизировать код невозможно.
Например, если я перегружу operator new так, чтобы он выбрасывал не bad_alloc, то компилятор не сможет переместить присваивание в секцию catch, также, как и не сможет удалить его. Хотя он способен инициализировать нулем переменную сразу, потому как, между объявлением и присваиванием больше ничего не делается с данной переменной.

[Sheogorath]

Ясно, всем спасибо за помощь.