какого шанса этого ПР попасть в С++26 ? Обсуждается оно?
@antoshkka
Надеюсь, что никакого. Никаких причин пихать это в стандарт нет. Делайте ключик компилятора, передавайте и наслаждайтесь
Чтобы помедленнее было?
Там в ПРе это вопрос изучен - не станет ли программа медленее. По их статистика, будет медленне в текущий время примерно 0.5-1% не больше, а надеется на будущем ещё меньше разницу. Конечно как они проводили это, я хз).
Ещё предлагает, три разный возможности оставаться не инициализированный как раньше: [[uninitialized] int a; //(1) int b = void; //(2) int c = std::uninitialized; //(3) И стандарту предлагает, выбрат один из них.
Вариант с атрибутом явно плох, ибо сейчас не диагностируется, что его нет
3 варианта исправления проблемы, которой без этого пропозала просто не существует 🤦♂️
1% - это огромная величина потери производительности для такой маленькой (и бесполезной) фички.
вряд ли бесполезная, плюс не стоит забывать о том что компилятор всё ещё может оптимизировать инициализацию переменной, не всегда, конечно, но может
Обсуждается, ыло отправлено из подгруппы Core с фидбеком "нужен механизм для явного отключения для выбраных переменных"
Сомневаюсь, что подобное соптимизируется: char buffer[Xxx]; SomeCApi(buffer, Xxx, &result)
потому и предлагают, заменить неявный пропуск инициализации на явный и по-умолчанию неявно инициализировать переменную
...и переписать кучу кода, причем ещё неясно, где потенциально выстрелит в ногу
может и не выстрелит, но замедлится может
Обсуждают сегодня