Comments 7
Ну и второй вопрос, который по сути должен быть первым, зачем на этапе компиляции проверка на null? На этапе компиляции программист и так знает, null там или не null/
Что-то напомнил ваш комментарий.
А вообще на стеке выделять память быстрее. Так что, видимо, в целях оптимизации.
Использование кучи потенциально более медленно, особенно во многопоточных программах. Кроме того выделение памяти в куче это чаще всего не реентерабельная функция, соответственно optional стал бы тоже не реентерабельным.
Пожалуйста, поясните поподробнее про те бреши в безопасности, которые открывают объединения. До сих пор до конца не понимаю — чем мотивировались разработчики стандарта C++, запрещая доступ через неинициализированный член к данным constexpr объединения, инициализированных через другой член объединения. В чём именно опасность?
Самое главное, компилятор то откуда знает, какой член объединения активный? А если он об этом знает, то зачем нам собственный признак в виде initialized_
?
Конечно GNUC компилятор (g++) знает, что constexpr выражение создаётся из неинициализированного по common sequence initialization члена объединения реализованного как constexpr, а потому выдаёт подобную ошибку:
error: accessing ‘<alpha>’ member instead of initialized ‘<omega>’ member in constant expression
Меня всегда интересовала мотивация разработчиков стандарта и компиляторов, по которой принимаются те или иные, весьма сомнительные решения.
Использование объединений в константных выражениях под С++11