Позволяет ли стандарт C++ реализовывать std::option<double> без накладных расходов?

Question

Я только что наблюдал, как cppcon рассказывает о системе Bloomberg datum, типе варианта, который использует избыточность в формате IEEE754 для кодирования того, какой тип хранится в базе данных.

Поэтому мне было интересно, позволяет ли стандарт C++ для реализаций реализовывать std::option более эффективно, используя тот же трюк.

Обратите внимание, что для этого потребуется, чтобы иногда двоичное представление double, хранящееся в необязательном порядке, не совпадало с двоичным представлением double, переданным в конструктор.

примечания: я забочусь о стандартном разрешении этого или нет, я знаю, что большинство / все реализации не будут беспокоить.

Я знаю, что стандарт IEEE754 не предусмотрен стандартом, но он разрешен и проверяется реализацией.

Answer 1

Стандарт требует, чтобы, если вы храните значение в std::optional, тогда значение должно быть в состоянии получить точно так же, как сохранено. Кроме того, если optional<T> занимается, вы можете хранить любые T в optional значение, не позволяя optional знаю, что ты делаешь это. Как это:

optional<T> opt = T{};
auto &&val = *opt;
val = <insert value here>; //opt has no idea it has been set.

Из-за этого единственный верный способ optional<T> может быть оптимизирован для использования определенных значений T означать, что optional если пользователь не может создать T с этими ценностями. IEEE-754 реализации double может принимать любой бит-паттерн, и все они легальны (даже сигнализируют NaN).

Причина, по которой другие необязательные типы могут сделать это, заключается в том, что у них есть неявное соглашение с пользователем, что они не будут устанавливать для него определенные значения. std::optional<T> не имеет такого соглашения; любое значение, которое T Можно предположить, может быть сохранен и извлечен.

Сейчас если optional<T>::operator* а также optional<T>::value вернул какой-то объект прокси, а не прямую ссылку на T, тогда это может быть возможно, так как прокси может обрабатывать соответствующие преобразования. Но даже тогда стандарт должен был бы конкретно указать, что попытка установить его в одно из этих значений приведет к тому, что значение примет эквивалентное, но другое представление объекта.