Pull to refresh

Comments 35

Слишком быстро компилируется программа и нету времени почитать хабр?
Добавь в исходники жизни.
А потом можно даже заставить её эволюционировать средствами компилятора, а точнее оптимизатора, особо хорошо это получается у компилятора Intel, тогда времени будет ещё больше :)
Программисты С++ — самые читающие программисты в мире! )
Самые чиТающие :-)
Создав Жизнь, мы доказали сами себе полноценность шаблонов С++ как языка

Звучит классно :)

Собственно говоря, никто не сомневается в полноте по Тьюрингу шаблонов С++ и возможности написать на них хоть чёрта лысого. Беда в том, что код получается сложным и трудно поддерживаемым (взять хотя бы отладку). Нет практического коммерческого профита писать на них что-то сложнее разных разновидностей контейнеров и пары паттернов из числа классических.
Собственно говоря, никто не сомневается в полноте по Тьюрингу шаблонов С++ и возможности написать на них хоть чёрта лысого.
Я вроде бы написал на них рекурсивную функцию вычисления факториала, но порядок раскрытия и редукции шаблонов не позволяет вычислить результат её применения :(

Ну, хотя да. Шаблоны настолько круты, что на них можно выразить даже бесконечный цикл.
Закостылил рекурсию, теперь всё считает. Факториал шести — за 10 секунд. Факториал семи — падает с переполнением стека. Пойду дописывать статью.
Извините, возможно, я что-то не так понял, но что сложного в факториале на шаблонах С++?

template <int N>
struct fact {
    static const int value = N * fact<N-1>::value;
};

template <>
struct fact<1> {
    static const int value = 1;
};

int fact_5 = fact<5>::value; // = 120
Я более извращён. Там именно что функция, вычисляющая факториал. И интерпретатор (времени компиляции), который вычисляет результат применения этой функции.
Я где-то видел примеры статически конфигурируемых связей listener'ов на этапе компиляции.
Вот это было круто — все само связывается, и на этапе компиляции проверяет, что все связи действительно есть.
:-)
Жаль, не могу указать источник.
С каждым новым релизом количество способов нетривиально вывихнуть себе мозг при помощи С++ продолжает увеличиваться)
Жизнь на шаблонах можно написать и с использованием предыдущих стандартов С++, но как раз это сделало бы код более мозговывихивающим :)
Особенно, если не менять подход к реализации игрового поля и продолжать пытаться все вычисления выполнять не над константами, а над типами.
Хотите решить головоломку?
Напишите компилятор C++ на шаблонах C++. :-)
Дык используйте boost::spirit, вам обеспечены долгие часы чтения хабра :-D
>Еще тут обнаруживается новая возможность языка шаблонов — спецификация
Не спецификация, а специализация.
Я жажду слышать аргументы того, кто минусанул комментарий.
Как же, помню… Через тернии темлейтного метапрограммирования, boost, интервальная арифметика и символьное дифференцирование, сообщения об ошибках на 40 страниц, потом попытки реализовать доморощенный reflection и прочие плюшки для C++ на основе gccxml (это были ~2002-2003 годы)… Желание управлять процессом компиляции… Потом Scheme, hygienic macros… Мой долгий путь к Common Lisp'у. Здравствуй, defmacro :)
Очень красивый и емкий язык, для работы с которым нужно перевернуть мышление.
:-)
Вот закончу разбираться с 3D-графикой, и перейду на темную сторону силы — практиковаться в Lisp или Closure.
UFO just landed and posted this here
Для дальнейших извращений рекомендую А.Александреску «Modern C++ Design», а если этого будет мало, то можно обратить взор на D (в который и ушел автор этой книги), в нем не проблема сделать compile-time raytracer, да и скорость компиляции на порядок выше C++.
Эти идеи отлично применяются на практике. Например, NS-3 симулятор сети, который активно используется в научных исследованиях, сделан с использованием многих идей из этой книги. Там, например, Garbage Collector реализован через метапрограммирование в С++.
А вот замедлить вывод на экран не сможите.
Вывод на экран выполняется обычным cout, если после него вставить задержку — вывод можно будет замедлить. Но зачем?
Ну я эт к тому что шаблоны не всемогущи :) Хотя как то глупо получилось :(
Есть тьюринг-полные языки, а есть тьюринг-полный-пиз.ец языки.
Это лингвистическая конструкция вокруг слова «полный».
К счастью, в С++11 появился оператор decltype, который буквально означает «какой тип вернула бы функция, если бы мы ее вызвали». Применим его к tuple_cat и… убедимся, что tuple_cat все-таки принимает не голый тип «tuple», которым мы везде оперируем, а значение tuple. К счастью, в С++ имеется класс declval, который позволяет нам сделать вид, что значение все же существует, но его нельзя нигде использовать именно как значение. Этого достаточно.

Вот за это я и люблю С++. Чтобы костыль не падал, подопрем его другим, побольше, чтоб тот поддержал первый :D

И все же генерики шарпа мне нравятся больше. Да, нету возможности писать a + b и затем подставлять любые типы, но это же является и плюсом — строгая типизация, можно явно указать, что ожидается на вход функции, а ошибка имеет достаточно понятное описание, а темплейт-ошибка всегдав мне напоминает «выр-выр-выр» из Темного Рыцаря.

Но статья очень интересная, спасибо. Плюсанул.
А в openttd на поездах и семафорах счетчики и цифровые индикаторы реализовать можно…
Можно, пожалуйста, подробнее?
Скажите, у меня одного clang 3.4 не может скомпилировать исходник? Только gcc справляется…
А вот меня лично интересует другие два вопроса — сколько весит бинарник, и сколько памяти в runtime жрет все это дело :-)
:-)
Sign up to leave a comment.

Articles

Change theme settings