Какие операции языка C++ могут быть потенциально небезопасны?

Question

[aminought]

• Присваивание.
  
• Использование dynamic_cast для приведения ссылочных типов.
  
• Создание экземпляра класса.
  
• Неявное преобразование значений базовых типов.
  
• Передача объекта-класса в функцию по значению.
  

Вопрос с несколькими вариантами ответа из курса по C++ от Mail.ru. Гадать не вижу смысла, поэтому выкладываю вопрос здесь вместе со своими мыслями. Вообще, мне бы сначала определиться, что значит - небезопасная операция? Насколько я понял, это операция, которая скомпилируется, но может как-то неправильно отработать.
Присваивание - безопасная операция, проверяется во время компиляции.
Использование dynamic_cast для ссылочных типов - выбрасывается исключение, значит небезопасная.
Создание экземпляра класса - может произойти утечка ресурсов, если в конструкторе возникнет исключение, да и память может кончиться - небезопасная.
Неявное преобразование - по определению небезопасная, нужна проверка типов.
Передача по значению - может не хватить памяти для копии объекта, небезопасная.
Ответ неверный. Я свои мысли рассказал, теперь прошу вашей помощи.

Answer 1

[nirvimel]

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

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

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

Comments

[aminought]

Спасибо большое, ответ принят, теперь я всё понял.

[aminought]

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

[Антон Жилин]

aminought: Исключение не может бросить только 4 вариант.

[MiiNiPaa]

> преобразования значений базовых типов [...] само по себе [...] не может вызывать[...] неопределенного поведения

Попытка запихнуть DBL_MAX во foat, таки вызывает неопределённое поведение, так как вне диапазона представимых величин для float, а это вызывает UB, согласно 4.8/1

[nirvimel]

MiiNiPaa: Респект за ссылку на стандарт. Но на архитектуре x86 это UB ведет себя как раз таки определенно - всегда возвращает inf или -inf (в зависимости от знака операнда) и не вызывает никаких сторонних эффектов.

[MiiNiPaa]

> Но на архитектуре x86 это UB ведет себя как раз таки определенно

Вы совершаете классическую ошибку, предполагая что знаете во что скомпилируется ваш код. Во-первых компилятор оптимизирует код, предполагая что UB не может наступить в принципе. Если один вариант ведёт к UB, а другой не ведёт, компилятор предполагает, что первый вариант не случится никогда. Отсюда пропавшие проверки, всегда истинные условия и т.д. Во-вторых IEEE-плавучка стандартом не гарантирована. Включаете -ffast-math (полностью придерживающийся стандарта), и попытка запихнуть большой дабл во флоат скорее всего сломает программу.

[nirvimel]

MiiNiPaa: Когда я пишу на C++, то знаю, во что скомпилируется мой код (допустим, иногда могу ошибиться), когда мне совершенно все равно, во что он скомпилируется, то я пишу на python.
А -ffast-math у меня обычно включен постоянно, кроме производительности, он выдает более простой и короткий машинный код без лишних проверок и корректировок операндов/результатов в соответствии с какими-то правилами.
Упаковка double во float на SSE всегда осуществляется инструкцией CVTSD2SS, которая приводит любые значения вне диапазона к inf/-inf и не вызывает никаких исключений в CPU (точнее не больше возможных исключений, чем простое перемещение данных операндов).
На счет тихого удаления веток, ведущих к UB: это не относится к данному случаю, если компилятор не может заранее знать значение операнда, то он не может однозначно идентифицировать UB-кейс, следовательно не имеет право удалить эту ветку.

[nirvimel]

MiiNiPaa: Сейчас специально проверил:

#include <iostream>
#include <cfloat>

int main() {
    volatile double x = -FLT_MAX * 2;
    float y = x;
    std::cout << y;
};

компилируется в это:

sub	rsp, 24
mov	edi, OFFSET FLAT:_ZSt4cout
movss	xmm0, DWORD PTR .LC1[rip]
cvtsd2ss	xmm0, xmm0
cvtss2sd	xmm0, xmm0
call	_ZNSo9_M_insertIdEERSoT_
xor	eax, eax
add	rsp, 24
ret

То есть присутствует честная конвертация 32-битного плавающего в 64-битное (а потом обратно для вывода в поток).

Если убрать volatile, то выводится готовое значение -inf как константа 64-бит.
То есть даже на этапе компиляции действует правило, по которому значения вне диапазона должны приводится к inf/-inf. Каким стандартом руководствуется компилятор в данном случае? Или это у него самого такое UB?

Answer 2

[Максим Мосейчук]

Использование dynamic_cast для ссылочных типов - выбрасывается исключение, значит небезопасная.

Безопасная операция, т.к. исключение можно обработать.

Comments

[aminought]

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

Answer 3

[Константин Степанов]

Спорно: Присваивание.
Да: Использование dynamic_cast для приведения ссылочных типов.
Да: Создание экземпляра класса.
Возможно: Передача объекта-класса в функцию по значению

При dynamic_cast вполне можно нарваться на нулевой указатель или на невозможность приведения.
При создании экземпляра может упасть конструктор или тупо не быть памяти.

При присваивании, в обычной жизни, проблем не должно быть, но, в принципе, их можно создать банальным переопределением операции присваивания.

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

З.Ы. Насколько я понимаю, неявное преобразование базовых типов проверяется на этапе компиляции, если мы, конечно, не используем auto.