Если у меня есть строковый литерал, который используется только в

компайл-тайме, дает ли мне кто-то гарантии что он не попадет в бинарь? Если да, то кто?
Варианты ответа:
Стандарт.
Компилятор.
Линкер.
Гарантий нет.

гарантий нет

гарантий нет, скорее всего точно попадет в бинарь

в больших компиляторах сейчас не попадает, даже без оптимизаций

ого, не знал что так бывает

Гарантирует стандарт C++26 (конкретно https://wg21.link/P2361 )

Хмм, там достаточно конкретный список использований. Покрывает ли бумага такой кейс https://godbolt.org/z/sxTGhr1Wh? Выглядит как будто нет

у вас именно такой use case, когда в рантайме используется лишь часть строкового литерала?

нет, представте что там нормальная хеш функция, используется весь литерал

тогда нет, ваш use case этой бумагой не покрывается

немного не в тему, но зачем вам вообще нужна такая гарантия?

тогда вам правильно сказали, что гарантий нет можете завести баг в кланге, если он не покрывает ваш use case, хотя мог бы

Ну я спрашиваю как раз потому что наблюдаю что компиляторы выкидывают строки в таких юзкейсах. Но не нашел нигде чем бы это было гарантировано

Меньше строк - меньше бинарь - меньше вероятностей что уедет что-то конфиденциальное в бинарь

гарантировано quality of implementation, так сказать скорее всего оно довольно давно было заточено для -Os

Удивило что даже без оптимизаций все ведут себя так

ну как вам уже сказали, стандартизированных гарантий вам никто не дает, но на практике имплементации выкидывают любые строки, которые не используются

В эмбеддед обычно по определённым адресам пришибают метаинфу для скриптов и валидации что натягивают прошивку именно от этого девайса, а не левак. Даже иногда мини подписи туда толкают или контрольные суммы. Обычно за таблицей векторов прерываний. Не факт, что ему это надо, но такие практики есть)

ну как уже было сказано выше, имплементации имеют моду выкидывать мусор, поэтому лучше опираться на это и сделать consteval функции для подобных строк, чтобы уж точно гарантировать, что они будут использованы только во время компиляции

Точно, посмотрел внимательнее - у него задача наоборот, чтобы гарантированно не попало в бинарь

могу привести вот такой пример с CRC-64 https://godbolt.org/z/PfcaE8vse правда для него вам нужен C++20

я тоже слеповат, не заметил, что вообще не тому человеку отвечал :D

как там в 2027 году живётся?

Как ГЭККом разжились, неплохо стало, даже Когти Смерти почти не беспокоят

я как увидел слово ГЭКК в одном из чатов сразу зашел что это тут обсуждается, и не ошибся, то самое

Это прям 100% или опционально? И если да, то чем мотивирована такая обязательность (понятно, что неиспользуемый в рантайме литерал можно выкинуть, но зачем обязывать это делать)?

Хреновый способ сохранения секретности был выбран

ну если довести до логического финала (вообще не иметь бинарь) то вполне себе надёжный (нет бинаря — утекать неоткуда)

Гениально

Обязательно. Просто это все делают, так что прописали в стандарте )

Имхо поспешили, хватило бы разрешения так делать

Кстати, там noexcept в механизм частичной специализации не собираются завозить? Чтобы делать такое: template <typename T> struct Foo; template <typename Ret, typename ... Args, bool nx> struct Foo<Ret(Args...) noexcept(nx)> { ... };

так оно и сейчас вроде работает?

Там требуется тип. В типе можно писать noexcept(expr)?

Foo<void() noexcept(true)> вы про это?

Да. Я не уверен, что так можно

Только в gcc и шланге и является расширением

Надо чтобы вместо true выводился параметр шаблона в специализации

он и выводится в специализации же?

Формально нет, но gcc и шланг умеют

в 23 стандарте видимо пофиксят)