Комментарии 45
Круто! А я вот CityHash 32/64/128-битный считал во время компиляции.
Я немного отстал от жизни С++.
Получается теперь компилятору можно сегфолт устроить?
Что он будет в этом случае делать?
Констекспры можно как-то дебажить?
Получается теперь компилятору можно сегфолт устроить?
Что он будет в этом случае делать?
Констекспры можно как-то дебажить?
Сегфолт нельзя.
Дебажить тоже нельзя. Но если вам требуется дебажить constexpr, то вы мсье. :)
constexpr char* s = "str";
constexpr char* q = s + 10; // не скомпилируется
Дебажить тоже нельзя. Но если вам требуется дебажить constexpr, то вы мсье. :)
Компилятор тщательно следит за тем, что делают
Еще в
Также компилятор ловит переполнение стека. В GCC по умолчанию глубина стека равна 512. В случае переполнения можно получить красивую ошибку из 512 строчек. С помощью флага можно расширить глубину стека.
А дебажить
constexpr-функции. В случае деления на ноль, компилятор выдаст ошибку, показывая при этом стек вызовов.Еще в
constexpr-функциях все переменные должны быть инициализированы, из-за чего не получится использовать неинициализированную переменную.Также компилятор ловит переполнение стека. В GCC по умолчанию глубина стека равна 512. В случае переполнения можно получить красивую ошибку из 512 строчек. С помощью флага можно расширить глубину стека.
А дебажить
constexpr затрудительно. Но это можно сделать, запустив функцию в runtime (например, передав в качестве параметра не constexpr-переменную).
error: constexpr variable cannot have non-literal type 'const std::regex' (aka 'const basic_regex<char>')
constexpr std::regex pattern("(0-9)");Эх. Когда подобное будет возможно, без re2c — будет очень круто.
Будем надеяться, что в C++14 или в C++17 добавят
constexpr regex. Вообще после С++14 из-за того, что уберут много ограничений на constexpr-функции и классы, можно будет почти всю стандартную библиотеку переписать, используя constexpr.
Зачем нужно переписывать стандартную библиотеку?
Я имел ввиду, что разработчики компиляторов могут ее переписать (если это будет соотчествовать стандарту), тем самым увеличив производительность.
Переписывание стандартной библиотеки с мечтами об увеличении производительности не имеет смысла, потому что STL активно использует кучу. А с тем небольшим множеством функций, которое можно обернуть в constexpr (div, abs, max, min), компилятор может справиться сам. Переписывать стоит только лишь для возможности использовать эти функции внутри пользовательского кода с constexpr.
Перестаньте считать компилятор настолько тупым, что он не может свернуть вычисление констант самостоятельно =)
Перестаньте считать компилятор настолько тупым, что он не может свернуть вычисление констант самостоятельно =)
На самом деле далеко не весь STL использует кучу. std::array или уже упомянутый std::regex — прямые кандидаты в переписывание на constexpr. Чтобы автомат для распознавания regexp'ов строился по время компиляции. Хотя надо посмотреть на интерфейсы — можно ли там будет обойтись без выделения памяти (с помощью шаблонов, к примеру).
Я пойму, что у меня настал чёрный день, когда увижу эту строчку в выводе компиляции при сборке чужого проекта.
Встроили-бы уже в язык нормальный интерпретатор и не мучались. И ключевое слово «interpret» для отделения того, что должно интепретироваться от того, что должно компилироваться.
constexpr как раз это и позволяет сделать (в C++11 не очень удачно). Но преимущество constexpr-функций в том, что в случае невозможности вызова функции на этапе компиляции, она запуститься в runtime, из-за чего не надо будет делать два экземпляра каждой функции.
а хотя бы warning в таком случае выдается, или он молча «глотает» ошибку?
Я бы не назвал это ошибкой.
Если вы хотите получить гарантию того, что результат будет посчитан на этапе компиляции, достаточно приравнять результат функции
Если вы хотите получить гарантию того, что результат будет посчитан на этапе компиляции, достаточно приравнять результат функции
constexpr-переменной.constexpr int n = get_n(); // теперь в случае невозможности использовать constexpr-функцию будет выведена ошибка
Поведение аналогично этому:
Аналогично в том смысле, что если функция вернет константу — совсем не означает, что использовать результат функции можно только как константу.
#include <iostream>
struct foo {
int bar;
foo(int bar) : bar(bar) {}
const int &getBar() {
return bar;
}
};
int main () {
foo f(5);
int bar = f.getBar();
bar = 10;
std::cout << f.bar << " " << bar << std::endl; // 5 10
}
Аналогично в том смысле, что если функция вернет константу — совсем не означает, что использовать результат функции можно только как константу.
Странно это всё — ограничений много, код сложный, профит — небольшой. В конце-концов уже давно люди использовали подход с генераторами кода С++ с помощью других инструментов (moc, батники, скрипты на интерпретируемых языках), которые сгенерят тебе всё что угодно, без ограничений, с понятным исходным кодом и без затрат на рантайме.
Что бы ни делать, лишь бы не вводить в язык нормальные синтаксические макросы.
а где по вашему нормальные синтаксические макросы (кроме TH) имеют место быть?
(спрашиваю информации ради).
(спрашиваю информации ради).
В большинстве диалектов LISP'а, как бы.
это верно, но я не стал упоминать, поскольку все диалекты лиспа динамически типизированы. А C++ типизирован статически (ну почти). Кроме того у лиспов есть уникальная, отличная от большинства языков, особенность — программа и данные записываются в одном и том же виде и имеют в корне одну и ту же структуру данных. Грех не изобрести понятие макроса.
Далеко не факт, что лисповская система макросов (и common lisp, и scheme) может быть построена над плюсами. Но и далеко не факт, что некое подобие Template Haskell тоже можно было бы построить над плюсами, потому что плюсы не функционально чисты.
Поэтому, хорошая система макросов в не функционально чистых статически типизированных языках — редкость. Разве что Nemerle стоит упомянуть.
Далеко не факт, что лисповская система макросов (и common lisp, и scheme) может быть построена над плюсами. Но и далеко не факт, что некое подобие Template Haskell тоже можно было бы построить над плюсами, потому что плюсы не функционально чисты.
Поэтому, хорошая система макросов в не функционально чистых статически типизированных языках — редкость. Разве что Nemerle стоит упомянуть.
>> Далеко не факт, что лисповская система макросов (и common lisp, и scheme) может быть построена над плюсами.
Лисповская система макросов может быть построена над любым языком, поскольку любую грамматику можно записать в виде s-выражений — нужно просто добавить преобразование туда и обратно.
На практике, конечно, неплохо еще иметь какой-нибудь сахар для обычный грамматики, с quotations и всем таким прочим. Но это именно сахар.
Лисповская система макросов может быть построена над любым языком, поскольку любую грамматику можно записать в виде s-выражений — нужно просто добавить преобразование туда и обратно.
На практике, конечно, неплохо еще иметь какой-нибудь сахар для обычный грамматики, с quotations и всем таким прочим. Но это именно сахар.
>> Лисповская система макросов может быть построена над любым языком, поскольку любую грамматику можно записать в виде s-выражений — нужно просто добавить преобразование туда и обратно.
после этого вы получите не с++, а лисп. Причем, довольно кривой раздутый диалект на котором разработчик будет писать только под пистолетом. Предлагаю вам переписать примеры из этой статьи в виде S-выражений (с правилами, которые вы сами придумаете), и убедиться что статически-типизированная семантика очень коряво ложится на S-выражения.
>> На практике, конечно, неплохо еще иметь какой-нибудь сахар для обычный грамматики, с quotations и всем таким прочим. Но это именно сахар.
макросы — это и есть частный случай синтаксического сахара. Их цель — сделать удобным написание и улучшить читабельность кода. Если вы попытаетесь записать какой-либо другой, отличный от лиспа язык, в S-выражения, вы, скорее всего (не всегда), и то и другое ухудшите. Поэкспериментируйте.
Поэтому лисповская система макросов чаще удобна только для лиспа. И именно поэтому, IMHO, в современном мире бизнес-логику в S-выражениях писать не принято, поскольку для этого почти всегда нужен талант и опыт, чтобы создать юзабельный и краткий DSL, а людей с такими качествами не много.
после этого вы получите не с++, а лисп. Причем, довольно кривой раздутый диалект на котором разработчик будет писать только под пистолетом. Предлагаю вам переписать примеры из этой статьи в виде S-выражений (с правилами, которые вы сами придумаете), и убедиться что статически-типизированная семантика очень коряво ложится на S-выражения.
>> На практике, конечно, неплохо еще иметь какой-нибудь сахар для обычный грамматики, с quotations и всем таким прочим. Но это именно сахар.
макросы — это и есть частный случай синтаксического сахара. Их цель — сделать удобным написание и улучшить читабельность кода. Если вы попытаетесь записать какой-либо другой, отличный от лиспа язык, в S-выражения, вы, скорее всего (не всегда), и то и другое ухудшите. Поэкспериментируйте.
Поэтому лисповская система макросов чаще удобна только для лиспа. И именно поэтому, IMHO, в современном мире бизнес-логику в S-выражениях писать не принято, поскольку для этого почти всегда нужен талант и опыт, чтобы создать юзабельный и краткий DSL, а людей с такими качествами не много.
Не соглашусь. Макросы — это не синтаксический сахар. Точнее, один конкретно взятый макрос — это сахар, но сама концепция в целом — нет, т.к. без макросов эквивалентные вещи описываются только с повторениями. Так можно договориться до того, что функции тоже сахар (а что, их же можно руками поинлайнить).
То, что это будет неудобно на практике с s-выражениями в плюсах — это другой разговор.
То, что это будет неудобно на практике с s-выражениями в плюсах — это другой разговор.
Из того что я знаю — язык Nemerle, на rsdn.ru есть отличные статьи по этому поводу. Думаю, еще где-нибудь есть.
Хотя можно обобщить и сказать, что основная идея нормального метапрограммирования — написание «плагинов к компилятору» с использованием классической императивной (процедурной и объектно-ориентированной) парадигмы, причем неважно на том же языке что и основная программа, или на каком-то другом (возможно на упрощенном подмножестве основного языка, или на популярном скриптовом языке). Это не генерация текста программы, а именно работа с синтаксическими деревьями, поэтому компилятор должен предоставлять какое-то API для доступа к себе, а синтаксис основного языка обеспечивать прозрачное встраивание макросов и «квазицитирование» кода.
Хотя можно обобщить и сказать, что основная идея нормального метапрограммирования — написание «плагинов к компилятору» с использованием классической императивной (процедурной и объектно-ориентированной) парадигмы, причем неважно на том же языке что и основная программа, или на каком-то другом (возможно на упрощенном подмножестве основного языка, или на популярном скриптовом языке). Это не генерация текста программы, а именно работа с синтаксическими деревьями, поэтому компилятор должен предоставлять какое-то API для доступа к себе, а синтаксис основного языка обеспечивать прозрачное встраивание макросов и «квазицитирование» кода.
Интересно было бы посмотреть на реализацию парсер-комбинаторов, как boost::spirit, только на constexpr-ах.
Это как раз задача для функционального программирования.
Это как раз задача для функционального программирования.
добро пожаловать под кат!
прочитал как «добро пожаловать в ад!»
и… не ошибся.
В целом полезная статья, но бросились в глаза несколько неточностей/непонятностей.
Это неверно. Ошибка в данном случае заключается не в том, что происходит попытка преобразования
Вот это тоже непонятно.
является как раз такой функцией, если я не ошибаюсь. Что может заставить эту функцию отрабатывать не в компайл тайме (кроме конкретной реализации компилятора)?
Непонятная фраза. Могут работать с объектами? А обычные не могут?
constexpr int b = inc (a); // ошибка: преобразование int -> constexpr int
Это неверно. Ошибка в данном случае заключается не в том, что происходит попытка преобразования
int в constexpr int, а в том, что a не является constexpr выражением, а такого типа, как constexpr int вообще не существует, так как constexpr не является частью типа, поэтому никаких попыток преобразования не делается.То есть не получится создать исключительно constexpr-функцию, которая может работать только на этапе компиляции.
Вот это тоже непонятно.
constexpr int inc (int a)
{
return a + 1;
}
является как раз такой функцией, если я не ошибаюсь. Что может заставить эту функцию отрабатывать не в компайл тайме (кроме конкретной реализации компилятора)?
Также constexpr-функции могут работать с объектами, это будет рассмотрено позже.
Непонятная фраза. Могут работать с объектами? А обычные не могут?
Спасибо за конструктивный отзыв!
Тут вы правы, поправил статью.
Любую constexpr-функцию можно запустить в runtime, для этого достаточно передать аргумент, который нельзя посчитать на этапе компиляции. Напомню, что компилятор может посчитать на этапе компиляции выражения, которые содержат только литералы или constexpr-переменные и constexpr-функции.
Возможно, я не очень понятно это написал. Имелось ввиду, что constexpr-функции могут работать не только с базовыми типами, но и с классами.
constexpr int b = inc (a); // ошибка: преобразование int -> constexpr int
Это неверно. Ошибка в данном случае заключается не в том, что происходит попытка преобразования int в constexpr int, а в том, что a не является constexpr выражением, а такого типа, как constexpr int вообще не существует, так как constexpr не является частью типа, поэтому никаких попыток преобразования не делается.
Тут вы правы, поправил статью.
То есть не получится создать исключительно constexpr-функцию, которая может работать только на этапе компиляции.
Вот это тоже непонятно.
Любую constexpr-функцию можно запустить в runtime, для этого достаточно передать аргумент, который нельзя посчитать на этапе компиляции. Напомню, что компилятор может посчитать на этапе компиляции выражения, которые содержат только литералы или constexpr-переменные и constexpr-функции.
Также constexpr-функции могут работать с объектами, это будет рассмотрено позже.
Непонятная фраза. Могут работать с объектами? А обычные не могут?
Возможно, я не очень понятно это написал. Имелось ввиду, что constexpr-функции могут работать не только с базовыми типами, но и с классами.
Любую constexpr-функцию можно запустить в runtime, для этого достаточно передать аргумент, который нельзя посчитать на этапе компиляции.
Я скорее имел в виду всю фразу целиком
Параметры функций не могут быть constexpr. То есть не получится создать исключительно constexpr-функцию, которая может работать только на этапе компиляции.
Время вычисления функции зависит не от параметров (аргументов), а от того в каком контексте она используется. Например,
constexpr int foo(int i); // Здесь foo() может быть вычислена и в рантайме и в
const int j = foo(2); // компайлтайме, несмотря, что её аргументом является constexpr
constexpr int foo(int i); // А здесь foo() обязаны быть вызвана в
constexpr int j = foo(2); // компайлтайме
Я к тому, что у вас не то, чтобы неправильно написано, а немного непонятно, не на то акцент сделан.
constexpr int foo(int i); // Здесь foo() может быть вычислена и в рантайме и в
const int j = foo(2); // компайлтайме, несмотря, что её аргументом является constexpr
constexpr int foo(int i); // А здесь foo() обязаны быть вызвана в
constexpr int j = foo(2); // компайлтайме
В первом случае функция обязана быть вызвана в compile-time, несмотря на то, что ее значение приравнивается не
constexpr-переменной, так как функция обязана вызвана в compile-time, если ее параметры можно посчитать на этапе компиляции.Бывают такие случаи, когда сложно уследить за тем, чтобы все параметры могли посчитаться на этапе компиляции, и как раз приравнивание значение гарантирует то, что функция будет вызвана в compile-time (в противном случае будет выведена ошибка).
Так что время вычисления функции зависит только от параметров.
===
return (y == 0)? throw std::logic_error («x can't be zero»): (y / x);
В случае вызова функции во время компиляции мы увидим ошибку, что конструкция throw не может находиться в constexpr-функции, а в runtime функция выбросит
===
Если ошибка выявляется на этапе компиляции, то о каком runtime-е речь? Кроме того, тут ещё ошибка в том, что типы второго и третьего операндов тернарного оператора должны быть одинаковыми либо приводиться друг к другу.
И если уж совсем придираться, то в условии должно проверяться х==0, а лучше даже 0==x ;)
return (y == 0)? throw std::logic_error («x can't be zero»): (y / x);
В случае вызова функции во время компиляции мы увидим ошибку, что конструкция throw не может находиться в constexpr-функции, а в runtime функция выбросит
===
Если ошибка выявляется на этапе компиляции, то о каком runtime-е речь? Кроме того, тут ещё ошибка в том, что типы второго и третьего операндов тернарного оператора должны быть одинаковыми либо приводиться друг к другу.
И если уж совсем придираться, то в условии должно проверяться х==0, а лучше даже 0==x ;)
В случае запуска этой функции в runtime (это возможно сделать, передав в функцию параметр, который нельзя посчитать на этапе компиляции), будет выброшено исключение.
Вообще GCC выполняет код по мере необходимости (по стандарту он может проверять весь constexpr-код сразу, но он этого не делает). Так что если
Вообще GCC выполняет код по мере необходимости (по стандарту он может проверять весь constexpr-код сразу, но он этого не делает). Так что если
y не будет равняться нулю, то кусок кода после '?' будет проигнорирован. Но чтобы вопросов не было, можно это переписать таким образом:return (y == 0)? (throw std::logic_error («x can't be zero»), 0): (y / x);
а почему не использовать static_assert вместо throw?
Цитата из статьи:
Когда пишешь какую-то constexpr-функцию, которую потом будут часто использовать, хорошо бы возвращать читабельную ошибку. Тут можно ошибочно предположить, что static_assert как раз для этого подходит. Но static_assert использовать не получится, так как параметры функций не могут быть constexpr, из-за чего значения параметров не гарантированно будут известны на этапе компиляции.
Так и не понял, зачем нагромождать язык миллионом новых ключевых слов. Неужели компилятор сам не может понять, какую функцию можно выполнить на этапе компиляции, а какую нет
Например, чтобы указать компилятору, что данная функция (не помеченная как constexpr) не может вычислять значение в constexpr-контексте.
То есть для того, чтобы паре функций, которые мы почему-то не хотим разрешать в constexpr-контексте, было запрещено это делать — мы будем теперь навешивать аттрибут на тысячи всех остальных функций?
Нет, мы будем, конечно, куда деваться — но назвать это чем-то, кроме как ошибкой в дизайне языка сложно…
Нет, мы будем, конечно, куда деваться — но назвать это чем-то, кроме как ошибкой в дизайне языка сложно…
Начиная с C++14 constexpr может работать и в не константном режиме. Но обратно не работает, такой дизайн. Программист ведь имеет право не обозначать функцию constexpr, например в тех случаях когда он явно знает, что она не является чистой.
Начиная с C++14 constexpr может работать и в не константном режиме.Начиная с C++11.
Но обратно не работает, такой дизайн.Такая ошибка в дизайне. Очень большая, серьёзная и неприятная.
Программист ведь имеет право не обозначать функцию constexpr, например в тех случаях когда он явно знает, что она не является чистой.Однако он обязан это сделать в тех случаях, когда он хочет, чтобы её можно было использовать в
constexpr-выражениях. Однако зачастую — не может. Ибо в разных версиях C++ требования к constexpr-функциям разные и вы не можете пометить функцию как constexpr и сказав в документации «на старых C++ комиляторах эту функцию нельзя использовать в constexpr-выражениях». Вам приходится либо писать «для использования этой библиотеки вам потребуется C++17 компилятор», либо обмазывать всё ваше творение кучей #ifdefов.Что радикально отличается от случая когда бы помечались бы лишь функции, которые нельзя использовать в
constexpr-выражениях!Заметьте, кстати, что тот факт, что у вас функция помечена как constexpr нифига не значит, что её можно будет использовать в
constexpr-выражениях!Вот, например, такая функция:
constexpr int badfunc(bool to_be) {
if (to_be or not to_be) {
printf("Yeah, we are here!\n");
}
return 0;
}Извините, но
constexpr спецификатор в применении к функции — это 100% ошибка дизайна. Очень глупая. Хотя во времена C++11 она казалась разумной — но дальнейшее развитие языка показало, что это ни разу не так.Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Спецификатор constexpr в C++11 и в C++14