Сообщение Re: union требует конструктор, зачем так сделано? от 06.06.2023 16:43
Изменено 06.06.2023 16:58 Кодт
Re: union требует конструктор, зачем так сделано?
Здравствуйте, Sm0ke, Вы писали:
S>Собственно хочу создать через new массив элементов T без вызова их конструкторов, чтобы потом по требованию делать std::construct_at() только для отдельных элементов .
Массив std::optional<T> не нравится? Хочется сэкономить на булевых флажках? Или нужна непрерывность адресов элементов?
S>Если поместить этот T в union для отложенной инициализации, и у T есть конструктор по умолчанию не дефоолтный, то стандарт требует добавление в union тоже конструктора по умолчанию, даже если тот ничего не делает... Зачем так сделано?
Это сделано для определённости. Чтобы было понятно, какие члены живут в юнионе "из коробки".
S>Тобишь создам через new массив 50 элементов union и для каждого будет вызван конструктор в процессе.. Это же замедление!
S>Подскажите как лучше. Использовать aligned_storage нет желания, и reinterprete_cast тоже.
Ну заведи юнион, у которого будет первый член с тривиальным конструктором — какой-нибудь std::monostate dummy
На -O0, конечно, конструктор юниона будет вызываться (и ничего не делать), но уже на -O1 он выродится.
S>Собственно хочу создать через new массив элементов T без вызова их конструкторов, чтобы потом по требованию делать std::construct_at() только для отдельных элементов .
Массив std::optional<T> не нравится? Хочется сэкономить на булевых флажках? Или нужна непрерывность адресов элементов?
S>Если поместить этот T в union для отложенной инициализации, и у T есть конструктор по умолчанию не дефоолтный, то стандарт требует добавление в union тоже конструктора по умолчанию, даже если тот ничего не делает... Зачем так сделано?
Это сделано для определённости. Чтобы было понятно, какие члены живут в юнионе "из коробки".
S>Тобишь создам через new массив 50 элементов union и для каждого будет вызван конструктор в процессе.. Это же замедление!
S>Подскажите как лучше. Использовать aligned_storage нет желания, и reinterprete_cast тоже.
Ну заведи юнион, у которого будет первый член с тривиальным конструктором — какой-нибудь std::monostate dummy
На -O0, конечно, конструктор юниона будет вызываться (и ничего не делать), но уже на -O1 он выродится.
Re: union требует конструктор, зачем так сделано?
Здравствуйте, Sm0ke, Вы писали:
S>Собственно хочу создать через new массив элементов T без вызова их конструкторов, чтобы потом по требованию делать std::construct_at() только для отдельных элементов .
Массив std::optional<T> не нравится? Хочется сэкономить на булевых флажках? Или нужна непрерывность адресов элементов?
S>Если поместить этот T в union для отложенной инициализации, и у T есть конструктор по умолчанию не дефоолтный, то стандарт требует добавление в union тоже конструктора по умолчанию, даже если тот ничего не делает... Зачем так сделано?
Это сделано для определённости. Чтобы было понятно, какие члены живут в юнионе "из коробки".
S>Тобишь создам через new массив 50 элементов union и для каждого будет вызван конструктор в процессе.. Это же замедление!
S>Подскажите как лучше. Использовать aligned_storage нет желания, и reinterprete_cast тоже.
Ну заведи юнион, у которого будет первый член с тривиальным конструктором — какой-нибудь std::monostate dummy
S>Собственно хочу создать через new массив элементов T без вызова их конструкторов, чтобы потом по требованию делать std::construct_at() только для отдельных элементов .
Массив std::optional<T> не нравится? Хочется сэкономить на булевых флажках? Или нужна непрерывность адресов элементов?
S>Если поместить этот T в union для отложенной инициализации, и у T есть конструктор по умолчанию не дефоолтный, то стандарт требует добавление в union тоже конструктора по умолчанию, даже если тот ничего не делает... Зачем так сделано?
Это сделано для определённости. Чтобы было понятно, какие члены живут в юнионе "из коробки".
S>Тобишь создам через new массив 50 элементов union и для каждого будет вызван конструктор в процессе.. Это же замедление!
S>Подскажите как лучше. Использовать aligned_storage нет желания, и reinterprete_cast тоже.
Ну заведи юнион, у которого будет первый член с тривиальным конструктором — какой-нибудь std::monostate dummy
union TrulyUnion {
std::monostate dummy = {};
T data;
.....
};