Как я понимаю, старый стиль, когда константы определялись виде #define — деканонизировали и предали анафеме. Теперь есть constexpr.
constexpr для времени компиляции, хотя тип проверяется. Вообще зачем это нужно — можете ли пример привести? Вроде режим компиляции — это отдельный тьюринг-полный язык, но нафига?
Всегда ли вы используете constexpr для констант?
Почему не использовать просто const, который времени выполнения?
Здравствуйте, Shmj, Вы писали:
S>Как я понимаю, старый стиль, когда константы определялись виде #define — деканонизировали и предали анафеме. Теперь есть constexpr.
Задолго до появления constextr для определения констант было общепринято использовать просто const. Ты, как обычно, слышал звон, но не знаешь, где он. Почитал бы что-нибудь, что ли.
Здравствуйте, Shmj, Вы писали:
S>Почему не использовать просто const, который времени выполнения?
Чтоб не тратить время при старте приложения.
Более правильная постановка вопроса: почему бы вместо этого мета-онанизма, который пишется как бы на особом языке, не использовать внешний скрипт с кодогенерацией, который и рассчитает все эти константы?
Здравствуйте, T4r4sB, Вы писали:
TB>Где гарантия, что результат будет вычислен при компиляции? Есть какой-то список операций, дающий гарантию?
Есть такие места, где кроме констант компиляции ничего больше использовать нельзя, например, параметры шаблонов, значения перечислений, ключи оператора switch, размеры массивов и пр. Вот эти места, собственно, и являлись гарантами.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, rg45, Вы писали:
R>Есть такие места, где кроме констант компиляции ничего больше использовать нельзя, например, параметры шаблонов, значения перечислений, ключи оператора switch, размеры массивов и пр. Вот эти места, собственно, и являлись гарантами.
Ну допустим, я напишу
int a[2+3];
Какой шанс, что какой-то компилятор не захочет складывать 2+3? И что говорит стандарт?
Здравствуйте, rg45, Вы писали:
R>По моим оценкам, шансы близки к нулю, если компилятор хоть немного вменяемый, конечно.
Ну нужны не оценки, а гарантия на уровне стандарта, что компилятор сможет сложить константы.
Вроде тут есть: https://en.cppreference.com/w/cpp/language/constant_expression
То есть читаешь 37 пунктов, сложения констант там нет, значит компилятор обязан справиться
Здравствуйте, T4r4sB, Вы писали:
TB>Ну нужны не оценки, а гарантия на уровне стандарта, что компилятор сможет сложить константы. TB>Вроде тут есть: https://en.cppreference.com/w/cpp/language/constant_expression TB>То есть читаешь 37 пунктов, сложения констант там нет, значит компилятор обязан справиться
о том, что модификатор const можно использовать для объявления констант времени компиляции? Хорошо, давай допустим невероятное: компилятор не смог сложить константы — это как-то противоречит тому, что сказал я?
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, T4r4sB, Вы писали:
TB>Отсутствием гарантий, что компилятор действительно вычислит константу.
Для меня гарантии — это то как я могу использовать объявленную сущность, что я могу с ней делать. Мне важно, чтоб я мог ее использовать в определенных местах, где по нормам языка заявлено использование константных выражений:
const int N = 42;
enum E { e = N };
int a[N] {};
std::array<int, N> ar{};
switch (val)
{
case N: . . .
}
Если компилятор сможет каким-то магическим образом обеспечить мне такое использование без вычисления константы, то на здоровье — я все равно этого никак не почувствую.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, T4r4sB, Вы писали:
R>>По моим оценкам, шансы близки к нулю, если компилятор хоть немного вменяемый, конечно.
TB>Ну нужны не оценки, а гарантия на уровне стандарта, что компилятор сможет сложить константы. TB>Вроде тут есть: https://en.cppreference.com/w/cpp/language/constant_expression TB>То есть читаешь 37 пунктов, сложения констант там нет, значит компилятор обязан справиться
А давно в плюсики завезли массивы переменного размера? Чтобы в рантайме считалось?
Здравствуйте, rg45, Вы писали:
П>>А давно в плюсики завезли массивы переменного размера? Чтобы в рантайме считалось?
R>Только как расширения. По стандарту только константные размеры предусмотрены.
Ну вот я именно про это. Если компилятор не может вычислить эту константу, он должен сложить лапки
Здравствуйте, Shmj, Вы писали:
S> constexpr для времени компиляции, хотя тип проверяется. Вообще зачем это нужно — можете ли пример привести? Вроде режим компиляции — это отдельный тьюринг-полный язык, но нафига?
Здравствуйте, Shmj, Вы писали:
S>Как я понимаю, старый стиль, когда константы определялись виде #define
коллега (даже не читая ответы, то, что вы употребили есть препроцссор — вещь изначально не относящаяся к языку, т.е. в АСТ оно не попадает, оно генерирует то. что попадет в АСТ).
да а слово (ключевое) const именно с языка.
Здравствуйте, rg45, Вы писали:
R>Если компилятор сможет каким-то магическим образом обеспечить мне такое использование без вычисления константы, то на здоровье — я все равно этого никак не почувствую.
А если при попытке использовать другой компилятор окажется, что константа не вычислилась, то почувствуешь.
Здравствуйте, rg45, Вы писали:
R> А если динозавр, то бабушка может стать дедушкой.
Алё, я говорю, что если ты пишешь int a[2+3], то желательно иметь гарантию на уровне Стандарта, что выражение в квадратных скобках вычислится компилятором, что непонятного-то?
