Pull to refresh

Comments 6

А какой сакральный смысл хранить данные на стеке таким извращенным способом, почему просто нельзя сохранить указатель void* и в нужный момент вызвать new и delete?

Ну и второй вопрос, который по сути должен быть первым, зачем на этапе компиляции проверка на null? На этапе компиляции программист и так знает, null там или не null/
На каком-то форуме по Делфи давным-давно видел вопрос: как определить, какого типа переменная? На что ответили, что надо пролистать код вверх и посмотреть :)
Что-то напомнил ваш комментарий.
А вообще на стеке выделять память быстрее. Так что, видимо, в целях оптимизации.
>А какой сакральный смысл хранить данные на стеке таким извращенным способом, почему просто нельзя сохранить указатель void* и в нужный момент вызвать new и delete?

Использование кучи потенциально более медленно, особенно во многопоточных программах. Кроме того выделение памяти в куче это чаще всего не реентерабельная функция, соответственно optional стал бы тоже не реентерабельным.
А по поводу «На этапе компиляции программист и так знает, null там или не null» — с появлением constexpr-функций вычисления на этапе компиляции могут быть очень-очень сложными и сказать, что «программист же знает что там», это всё равно что сказать «зачем запускать программу, если можно в уме выполнить код её функций и узнать что там выйдет».

Пожалуйста, поясните поподробнее про те бреши в безопасности, которые открывают объединения. До сих пор до конца не понимаю — чем мотивировались разработчики стандарта C++, запрещая доступ через неинициализированный член к данным constexpr объединения, инициализированных через другой член объединения. В чём именно опасность?

Самое главное, компилятор то откуда знает, какой член объединения активный? А если он об этом знает, то зачем нам собственный признак в виде initialized_?

Sign up to leave a comment.