Здравствуйте, Аноним, Вы писали:

А>собственно какие возражения против шаблонов? Чем они отличаются от функциональнозапрограммированых макросов

Как программист на C++ с большим опытом, могу ответить: наверно, тем, что "метапрограммирование" на шаблонах в C++ это всего лишь жалкая пародия на макросы Nemerle? Наверно, потому что всё "метапрограммирование" на C++ есть не что иное, как использование набора трюков и побочных эффектов, тогда как макросы Nemerle являются штатной возможностью метапрограммирования, с которой язык заранее проектировался? Наверно, потому что шаблоны на C++ делают "криво" и сложно то, что макросы на Nemerle делают "прямо" и просто?

Здравствуйте, VladD2, Вы писали:

VD>Она не бесконечна.
Она бесконечна.
Единственное что ограничивает ее длинну это конечность памяти компьютера.
Но если принять это во внимание, то тогда придется признать, что не существует полных по Тьюрингу языков.

VD>Тогда твое решение тоже не принимается как машина тьюринга. Это некоторое приближение. Да и машины тьюрига универсальной не бывает. Она как конечный автомат, для каждого алгоритма новая.
Чего?
Машина Тьюринга это вычислитель. И она универсальна.
А для разных алгоритмов нужны разные программы, а не разные машины.

Здравствуйте, Аноним, Вы писали:

C>>Средства абстракции шаблонов тоже довольно слабые — у вас нету ни методов, ни классов, ни наследования, ни модулей. А набор примитивов довольно убог.
А>Опять же чисто функциональный. Что от него хочешь?

Хочу чтобы если функциональный — то как Хаскелл. Или хотя бы тот же Немерле. Не все чисто функциональные языки одинаковы... на Унламбде писать еще хуже чем на Брейнфаке.

А>Рано или поздно сделают удаление хвостовой рекурсии в внешних шаблонах.
Вот когда сделают компиляцию их в байт-код, можно будет говорить о скорости.

C>>Тем не менее, шаблоны не "плохи". Они чудесно выполняют свою главную функцию (поддержка обобщенного программирования), да еще и Тюринг-полны. Но в реалиях .НЕТ-а, имхо, более оптимальным выбором метапрограммирования являются макросы+генерики.
А>Возможно Просто шаблоны не сделаешь в нет

Я думаю, на макросах Немерле примитивный "шаблонизатор" (без рекурсии и специализации шаблонов) делается за несколько часов. Но никому он конечно не нужен, потому что работает только в рамках Немерле, а в Немерле есть макросы.

Здравствуйте, hardcase, Вы писали:

H>Это какойто ахтунг. Да и вообще все примеры шаблонов в C++ в этом топике какой-то ахтунг.
Я тебе скажу как краевед: Все примеры шаблонов С++ выходящие за приделы обобщенных контейнеров полный ахтунг.

Здравствуйте, CodingUnit, Вы писали:

Итааак...

>А как запустить шаблон из шаблона, с новыми аргументами?
Это я уже показал: http://rsdn.ru/forum/nemerle/4603395.1.aspx

Автор: Alexey F
Дата: 04.02.12

>Вот это не вполне понятно как можно произвести любое преобразование над любым деревом в шаблоне, например балансировку, поясните примером
Балансировка оказалась крепким орешком. Я не знаю, что я делал дольше — писал реализацию на Scheme в функциональном стиле или переводил на шаблоны C++. Функциональный стиль для некоторых алгоритмов мне не даётся до сих пор
Поэтому я позволил себе некоторую роскошь: вместо cons взял более привычный императивщикам (struct Node (value left right)) и цвет оставил прямо в структуре узла: (struct Node (value left right color)). Исходник на Scheme приводить не буду, т.к. он до страшного упрощён, чтобы было легче переводить в шаблоны, а результат — ниже.
Алгоритм принимает на вход сбалансированное бинарное дерево (именно дерево, не представляющий дерево список) и балансирует его. Вывод результатов ради удобства форматирования сделан в runtime.

	Код
	#include <cstdio> #include <string> enum Color { white, grey }; struct Null {}; template<int Value, class LeftType = Null, class RightType = Null, Color ColorValue = white> struct Node { static int const value = Value; typedef LeftType Left; typedef RightType Right; static Color const color = ColorValue; }; // --- template<class T, class U> struct Equal { static bool const value = false; }; template<class T> struct Equal<T, T> { static bool const value = true; }; // --- template<class T> struct IsLeaf { static bool const value = Equal<typename T::Left, Null>::value && Equal<typename T::Right, Null>::value; }; // --- template<class T> struct IsHaveRightChild { static bool const value = not Equal<typename T::Right, Null>::value; }; // --- template<class X> struct LeftTurn { typedef typename X::Right Y; typedef Node< Y::value, Node<X::value, typename X::Left, typename Y::Left>, typename Y::Right >> Result; }; // --- template<class Tree> struct TreeToLeftList; template<class Tree, bool Leaf, bool HaveRightChild> struct TreeToLeftListImpl; template<class Tree, bool HaveRightChild> struct TreeToLeftListImpl<Tree, true, HaveRightChild> { typedef Tree Result; }; template<class Tree> struct TreeToLeftListImpl<Tree, false, true> { typedef typename LeftTurn<Tree>::Result Transformed; typedef typename TreeToLeftList<Transformed>::Result Result; }; template<class Tree> struct TreeToLeftListImpl<Tree, false, false> { typedef typename TreeToLeftList<typename Tree::Left>::Result Left; typedef Node<Tree::value, Left> Result; }; template<class Tree> struct TreeToLeftList { typedef typename TreeToLeftListImpl<Tree, IsLeaf<Tree>::value, IsHaveRightChild<Tree>::value>::Result Result; }; // --- template<class Tree> struct TreeLeftLength { static std::size_t const value = 1 + TreeLeftLength<typename Tree::Left>::value; }; template<> struct TreeLeftLength<Null> { static std::size_t const value = 0; }; // --- template<class X> struct RightTurn { typedef typename X::Left Y; typedef Node< Y::value, typename Y::Left, Node<X::value, typename Y::Right, typename X::Right> >> Result; }; // --- template<std::size_t Value> struct IsPowerOfTwo { static bool const value = (( Value & ( Value - 1 )) == 0) && Value != 0; }; // --- template<class Tree, std::size_t Addition = 1> struct CorrectTree; template<class Tree, std::size_t Addition, bool End> struct CorrectTreeImpl { typedef typename RightTurn<Tree>::Result Transformed; typedef Node<Transformed::value, typename CorrectTree<typename Transformed::Left, Addition + 1>::Result, typename Transformed::Right> Result; }; template<class Tree, std::size_t Addition> struct CorrectTreeImpl<Tree, Addition, true> { typedef Tree Result; }; template<class Tree, std::size_t Addition> struct CorrectTree { typedef typename CorrectTreeImpl< Tree, Addition, IsPowerOfTwo<TreeLeftLength<Tree>::value + Addition>::value >>::Result Result; }; // --- template<class Tree> struct IsEnd { static bool const value = Tree::Left::color == grey; }; template<int Value, class Right, Color ColorValue> struct IsEnd< Node<Value, Null, Right, ColorValue> > { static bool const value = true; }; // --- template<class Tree> struct BalanceStep; template<class Tree, bool IsEnd> struct BalanceStepImpl; template<class Tree> struct BalanceStepImpl<Tree, true> { typedef Node<Tree::value, typename Tree::Left, typename Tree::Right, grey> Result; }; template<class Tree> struct BalanceStepImpl<Tree, false> { typedef typename RightTurn<Tree>::Result Transformed; typedef typename Transformed::Left Left; typedef typename Transformed::Right Right; typedef Node< Transformed::value, typename BalanceStepImpl<Left, IsEnd<Left>::value>::Result, Node<Right::value, typename Right::Left, typename Right::Right, grey> >> Result; }; template<class Tree> struct BalanceStep { typedef typename BalanceStepImpl<Tree, IsEnd<Tree>::value>::Result Result; }; template<class Tree, bool isEnd> struct BalanceImpl { typedef typename BalanceStep<Tree>::Result CurrentTree; typedef typename BalanceImpl<CurrentTree, IsEnd<CurrentTree>::value>::Result Result; }; template<class Tree> struct BalanceImpl<Tree, true> { typedef Tree Result; }; // --- template<class Tree> struct Balance { typedef typename TreeToLeftList<Tree>::Result LeftList; typedef typename CorrectTree<LeftList>::Result CorrectedTree; typedef typename BalanceStep<CorrectedTree>::Result CurrentTree; typedef typename BalanceImpl<CurrentTree, IsEnd<CurrentTree>::value>::Result Result; }; // ---- template<class T> struct Printer; template<> struct Printer<Null> { static void print( std::size_t const level = 0, bool const printNull = true ) { if( printNull ) { std::string tabs( level, ' ' ); std::printf( "%s[none]\n", tabs.c_str() ); } } }; template<int Value, class Left, class Right, Color ColorValue> struct Printer< Node<Value, Left, Right, ColorValue> > { static void print( std::size_t const level = 0, bool = true ) { std::string tabs( level, ' ' ); std::printf( "%s%d\n", tabs.c_str(), Value ); if( not IsLeaf< Node<Value, Left, Right, ColorValue> >::value ) { Printer<Left>::print( level + 1 ); Printer<Right>::print( level + 1, false ); } } }; // --- typedef Node<20, Node<14, Node<10, Node<7, Node<5, Node<3>, Node<6> >> >>, Node<11, Null, Node<12> >> >> >>, Node<25> >> Graph1; typedef Node<1, Null, Node<6, Node<4, Node<2, Null, Node<3> >>, Node<5> >>, Node<13, Node<8, Node<7>, Node<12, Node<9, Null, Node<11, Node<10> >> >> >> >>, Node<14, Null, Node<15> >> >> >> >> Graph2; int main() { Printer<Graph1>::print(); std::puts( "" ); Printer<Balance<Graph1>::Result>::print(); std::puts( "===" ); Printer<Graph2>::print(); std::puts( "" ); Printer<Balance<Graph2>::Result>::print(); }

Вывод (бинарное дерево, сбалансированное дерево, разделитель "===", [none] == "левый узел отсутствует"):

	Вывод
	20 14 10 7 5 3 6 11 [none] 12 25 7 5 3 6 12 10 [none] 11 20 14 25 === 1 [none] 6 4 2 [none] 3 5 13 8 7 12 9 [none] 11 10 14 [none] 15 8 4 2 1 3 6 5 7 12 10 9 11 14 13 15

Здравствуйте, Аноним, Вы писали:

А>Что мешает эту прагму использовать в шаблонах и получать сообщения об ошибках? Эта прагма не более чем printf

Мешают сразу две вещи.

1. Прагма не является частью языка и не может быть испльзована в переносимомо коде.
2. Она выведет сообщение не во время воплощения (инстанциации, как это дело часто называют) шаблона, и не в зависимости от условий, а тупо при обработке компилятором строки файла в котором она применяется.

Короче, вот тебе простой макрос. Попробуй его повторить на С++:

macro Hello(name : string, count : int)
{
  if (count <= 0)
    Message.Error("The parameter 'count' must be greater than 0.");
  else repeat (count)
    Message.Hint($"Hello, $name!");

  <[ () ]> // ничего не генерировать в программе
}

И это еще так, цветочки. Макросы в отличии от шаблонов ведь могут анализировать код, читать данные из внешних источников (вплоть до баз данных), типизировать полученные выражения и генерировать, на основании всего этого специализированный код. Причем код макроса — это откомпилированный код по скорости не отличающийся от кода самого компилятора. В отличии от шаблонов, вычисления в которых делаются на побочных эффектах весьма дорогостоящих операций вроде рекурсивного воплощения шаблонов.

Здравствуйте, Аноним, Вы писали:

А>собственно какие возражения против шаблонов? Чем они отличаются от функциональнозапрограммированых макросов

(я про шаблоны С++ в этом посте)

Мне кажется, главный недостаток шаблонов в том, что с их помощью очень тяжело запрограммировать что-то, для чего они изначально не предназначены, то есть любые операции не с типами. Допустим, у вас вряд ли выйдет легко написать быструю программу на шаблонах, которая бы выполняло арифметику с плавающей запятой.

Средства абстракции шаблонов тоже довольно слабые — у вас нету ни методов, ни классов, ни наследования, ни модулей. А набор примитивов довольно убог.

Ввод-вывод ограничен. С инклюдом

Автор:
Дата: 04.02.12

вы хорошо выкрутились, но "outclude" нету, поэтому написать чего-то не выйдет. Это не говоря уже о доступе в сеть, использовании полноценного API потоков с буферизацией и так далее.

Про скорость нужно еще раз сказать. Макросы выполняются намного быстрее любых нетривиальных шаблонов.

Тем не менее, шаблоны не "плохи". Они чудесно выполняют свою главную функцию (поддержка обобщенного программирования), да еще и Тюринг-полны. Но в реалиях .НЕТ-а, имхо, более оптимальным выбором метапрограммирования являются макросы+генерики.

Здравствуйте, Аноним, Вы писали:

А>Что мешает эту прагму использовать в шаблонах и получать сообщения об ошибках? Эта прагма не более чем printf

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

Иначе ошибки STL визуал студии были бы понятнее, чем сейчас.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>собственно какие возражения против шаблонов? Чем они отличаются от функциональнозапрограммированых макросов

А>Как программист на C++ с большим опытом, могу ответить: наверно, тем, что "метапрограммирование" на шаблонах в C++ это всего лишь жалкая пародия на макросы Nemerle? Наверно, потому что всё "метапрограммирование" на C++ есть не что иное, как использование набора трюков и побочных эффектов, тогда как макросы Nemerle являются штатной возможностью метапрограммирования, с которой язык заранее проектировался? Наверно, потому что шаблоны на C++ делают "криво" и сложно то, что макросы на Nemerle делают "прямо" и просто?
Просто писать после императивного в чисто функциональном тяжело. Не понимаешь почему надо писать кучу кода вместо обычного императива. У вас есть опыт написания на чисто функциональном?

Здравствуйте, CodingUnit, Вы писали:

CU>Довольно странное определение, к чисто функциональным языкам относят языки неиспользующими деструктивные модификации, но в шаблонах С++ нет переменных как таковых, есть только типы и константы, порядок вычисления и поток выполнения не определен, то есть невозможно понять в каком порядке компилятор обработает их и невозможно отладить это. К тому же функциональные языки чтобы называться таковыми должны уметь выполнять типичные алгоритмы, можно ли на шаблонах построить дерево, сбалансировать, преобразовать в другой вид? Функции в этих языках первоклассные сущности, в шаблонах же нет функций как таковых преобразующих данные из одного в другой. Поэтому вряд ли их можно назвать чисто функциональным языком, это более надстройка во время компиляции для настройки системы типов, которую пытаются растянут чтобы получить некое метапрограммирование в терминах типов.
В шаблон можно передать шаблон. Шаблон есть первоклассный объект времени компиляции, аналогично функции в чисто функциональном. Для полноты достаточно альтернативы и рекурсии.
С отладкой проблемы. Но тут Просто никто не писал отладку. Представьте если бы в немерли было нельзя останавливать во время компиляции

Здравствуйте, CodingUnit, Вы писали:

CU>Может кому то все же очень хочется назвать этот язык шаблонов функциональным, ну пожалуйста называйте и используйте, мы же говорим не о терминах, а чем плохи шаблоны по сравнению с макросами Н, я эту разницу показал.
Шаблоны сложны в отладке так как не поддерживаются иде в отличии от макросов. Шаблоны медленны из за того что работают фактически в текстовом виде и не поддерживается компиляция шаблонов в отличии от макросов. Шаблоны сложны в понимании так как являются чистым функциональным языком в отличии от более привычным императивных. Как в чистом функциональном есть проблемы ввода вывода. Шаблоны в отличии от макросов не содержат сайтэффектов. Шаблоны не позволяют создавать произвольный синтаксис. Шаблоны близки к доказательному программированию

Здравствуйте, CodingUnit, Вы писали:

CU>Довольно странное определение, к чисто функциональным языкам относят языки неиспользующими деструктивные модификации, но в шаблонах С++ нет переменных как таковых, есть только типы и константы, порядок вычисления и поток выполнения не определен, то есть невозможно понять в каком порядке компилятор обработает их и невозможно отладить это.
Скажешь это не программа на чистом функциональном языке?
http://www.rsdn.ru/forum/philosophy/1910243.1.aspx

Автор: WolfHound
Дата: 22.05.06

Там есть функция MergeSort которая принимает список и предикат Int2TypeLess.

Если у меня вдруг появится настроение я даже машину Тьюринга на шаблонах могу изобразить.

Здравствуйте, Аноним, Вы писали:

А>собственно какие возражения против шаблонов? Чем они отличаются от функциональнозапрограммированых макросов

Анализ кода?
например можно сделать проверку функции на чистоту(правда никто пока не заморачивался) или статическую проверку контрактов целевой функции

удаление или модификация кода?
хотя это и в Н не приветствуется.

уже говорили, но повторюсь
введение синтаксиса,
ввод-вывод

и ещё много много того что невозможно либо очень трудно сделать в шаблонах но легко либо не очень сложно в Н

Здравствуйте, Alexey F, Вы писали:

AF>Здравствуйте, CodingUnit, Вы писали:

AF>Итааак...

>>А как запустить шаблон из шаблона, с новыми аргументами?
AF>Это я уже показал: http://rsdn.ru/forum/nemerle/4603395.1.aspx

Автор: Alexey F
Дата: 04.02.12

Да, алгоритм вам удался, получаются многие алгоритмы на шаблонах, но до каких же извращений вы дошли ребята. Я хоть и программлю на С++ по работе, но мне все же больше интересней работа с Н во время компиляции и перевод его в АСТ С++ и генерация кода. Так можно делать больше вещей во время компиляции и генерировать что нужно.

Здравствуйте, Аноним, Вы писали:

А>>>Достаточно безумная мысль так как немерле слишком завязан на нет и придется перетаскивать кучу библиотек нет что делает вашу работу сложной если не реальной.

WH>>Для Н2 это будет штатный режим работы.

А>Макросы стандартной библиотеки немерли не будут использовать стандартную библиотеку нет? Такое решение принято?

в данном случае не столько важно от чего зависят макросы.

важно то, что СГЕНЕРИРОВАННЫЙ ими код может НЕ ЗАВИСЕТЬ ни от чего

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, WolfHound, Вы писали:

WH>>>>Если у меня вдруг появится настроение я даже машину Тьюринга на шаблонах могу изобразить.
VD>>>Это вряд ли. Что будешь в качестве непрерывной ленты использовать?
WH>>Не забывай с кем разговариваешь...

VD>На вопрос то не хочешь ответить?

VD>Пойми есть огромная разница между полнотой по тьюрингу некоторой машины возможностью на ней воспроизвести саму эту машу в исходом описании.

нет разницы. Полнота по тьюрингу это возможность воспроизвести машину тьюринга.

Здравствуйте, VladD2, Вы писали:

VD>Да ладно конфиги читать. Ты попробуй, например, хотя бы сообщение пользователю во время компиляции выдать.

gamedev.ru/code/forum/?id=133522
легко

Здравствуйте, VladD2, Вы писали:

VD>Ну, тем что не макросы. Это примерно тоже самое, что спрашивать чем отличаются завод от автомобиля. С помощью автомобиля завод не сделать, а наоборот запросто.

Что-то мне кажется, что сделать шаблоны из макросов Nemerle — не запросто.

Здравствуйте, Аноним, Вы писали:

А>собственно какие возражения против шаблонов?

С++-ые что ли?

А>Чем они отличаются от функциональнозапрограммированых макросов

Ну, тем что не макросы. Это примерно тоже самое, что спрашивать чем отличаются завод от автомобиля. С помощью автомобиля завод не сделать, а наоборот запросто.

Здравствуйте, Аноним, Вы писали:

H>>Попробуйте прочитать конфиг шаблоном.

А>Делается через include. Но это уже не функциональный чисто функциональный. Да и тяжело очень.

Да ладно конфиги читать. Ты попробуй, например, хотя бы сообщение пользователю во время компиляции выдать.

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

Здравствуйте, Аноним, Вы писали:

А>собственно какие возражения против шаблонов?

Попробуйте прочитать конфиг шаблоном.

Здравствуйте, hardcase, Вы писали:

H>Попробуйте прочитать конфиг шаблоном.

Делается через include. Но это уже не функциональный чисто функциональный. Да и тяжело очень.

Здравствуйте, Аноним, Вы писали:

А>gamedev.ru/code/forum/?id=133522
А>легко

А можно конкретно носом тыкнуть, где там шаблоны? Я не С++-ник, поэтому шаблоны вижу только там где много угловых скобочек, а по линку ни одной. Я даже на страницу два зашел.

Здравствуйте, catbert, Вы писали:

C>Здравствуйте, Аноним, Вы писали:

А>>gamedev.ru/code/forum/?id=133522
А>>легко

C>А можно конкретно носом тыкнуть, где там шаблоны? Я не С++-ник, поэтому шаблоны вижу только там где много угловых скобочек, а по линку ни одной. Я даже на страницу два зашел.

Что мешает эту прагму использовать в шаблонах и получать сообщения об ошибках? Эта прагма не более чем printf

Здравствуйте, catbert, Вы писали:

C>(я про шаблоны С++ в этом посте)

C>Мне кажется, главный недостаток шаблонов в том, что с их помощью очень тяжело запрограммиовать что-то, для чего они изначально не предназначены, то есть любые операции не с типами. Допустим, у вас вряд ли выйдет легко написать быструю программу на шаблонах, которая бы выполняло арифметику с плавающей запятой.
Согласен. Тут сказывается проблема того что шаблоны представляют собой чистый функциональный язык в то время как с++ нет. Кроме того в шаблонах не предусмотрено удаление хвостовой рекурсии. Сложность программирования на шаблонах сравнима со сложностью программирования на haskell.

C>Средства абстракции шаблонов тоже довольно слабые — у вас нету ни методов, ни классов, ни наследования, ни модулей. А набор примитивов довольно убог.
Опять же чисто функциональный. Что от него хочешь?
C>Ввод-вывод ограничен. С инклюдом

Автор:
Дата: 04.02.12

вы хорошо выкрутились, но "outclude" нету, поэтому написать чего-то не выйдет. Это не говоря уже о доступе в сеть, использовании полноценного API потоков с буферизацией и так далее.

C>Про скорость нужно еще раз сказать. Макросы выполняются намного быстрее любых нетривиальных шаблонов.
Рано или поздно сделают удаление хвостовой рекурсии в внешних шаблонах.
C>Тем не менее, шаблоны не "плохи". Они чудесно выполняют свою главную функцию (поддержка обобщенного программирования), да еще и Тюринг-полны. Но в реалиях .НЕТ-а, имхо, более оптимальным выбором метапрограммирования являются макросы+генерики.
Возможно Просто шаблоны не сделаешь в нет

Здравствуйте, Аноним, Вы писали:

VD>>Да ладно конфиги читать. Ты попробуй, например, хотя бы сообщение пользователю во время компиляции выдать.

А>gamedev.ru/code/forum/?id=133522
А>легко

Это не серьезный ответ если мы говорим о шаблонах C++ а не прагма директивах препроцессора конкретного компилятора, вот в этом и заканчивается кажущаяся мощь шаблонов. Они предлагают свои возможности метапрограммирования, но по опыту это очень сложная и неудобная модель, которая работает еще и не на всех компиляторах, довольно ограниченная потому что позволяет делать очень мало и кода как такового из шаблона вызвать невозможно, поэтому вопрос чем они плохи по сравнению с макросами я думаю ясен.

Здравствуйте, Аноним, Вы писали:

А>Согласен. Тут сказывается проблема того что шаблоны представляют собой чистый функциональный язык в то время как с++ нет. Кроме того в шаблонах не предусмотрено удаление хвостовой рекурсии. Сложность программирования на шаблонах сравнима со сложностью программирования на haskell.

Так о каких таких шаблонах идет речь, если не о С++ и где там чисто функциональный язык и хвостовая рекурсия?

Здравствуйте, CodingUnit, Вы писали:

CU>Так о каких таких шаблонах идет речь, если не о С++ и где там чисто функциональный язык и хвостовая рекурсия?
Шаблоны C++, по-сути, являются чисто функциональным языком со специфичным ( ) синтаксисом, без сборщика мусора, отсутствием оптимизации хвостовой рекурсии и верхним пределом (обычно, не жёстко фиксированным) глубины рекурсивных вызовов. // Да дополнят и поправят меня, если я где-то ошибся.

Здравствуйте, CodingUnit, Вы писали:

CU>Так о каких таких шаблонах идет речь, если не о С++ и где там чисто функциональный язык и хвостовая рекурсия?

Шаблоны и есть чисто функциональный язык со всеми следующими из этого недостатками и преимуществами. Отсутствие ввода вывода, циклы через рекурсию, не возможность модифицировать значение. И плюсы потоко безопасность и отсутствие императивных эффектов.

Здравствуйте, Alexey F, Вы писали:

AF>Шаблоны C++, по-сути, являются чисто функциональным языком со специфичным ( ) синтаксисом, без сборщика мусора, отсутствием оптимизации хвостовой рекурсии и верхним пределом (обычно, не жёстко фиксированным) глубины рекурсивных вызовов. // Да дополнят и поправят меня, если я где-то ошибся.

Довольно странное определение, к чисто функциональным языкам относят языки неиспользующими деструктивные модификации, но в шаблонах С++ нет переменных как таковых, есть только типы и константы, порядок вычисления и поток выполнения не определен, то есть невозможно понять в каком порядке компилятор обработает их и невозможно отладить это. К тому же функциональные языки чтобы называться таковыми должны уметь выполнять типичные алгоритмы, можно ли на шаблонах построить дерево, сбалансировать, преобразовать в другой вид? Функции в этих языках первоклассные сущности, в шаблонах же нет функций как таковых преобразующих данные из одного в другой. Поэтому вряд ли их можно назвать чисто функциональным языком, это более надстройка во время компиляции для настройки системы типов, которую пытаются растянут чтобы получить некое метапрограммирование в терминах типов.

Здравствуйте, CodingUnit, Вы писали:

CU>Довольно странное определение, к чисто функциональным языкам относят языки неиспользующими деструктивные модификации, но в шаблонах С++ нет переменных как таковых, есть только типы и константы
Операции над типами и константами недеструктивны по определению Кто-то (remark? Сложно найти, когда форум отвечает на часть запросов фразой "Language color pattern source xml stream is not valid") на forum/cpp находил способ запоминать кое-какое состояние между вызовами шаблонов, но в результате пришли к выводу, что этот спецэффект возник из-за недочёта реализации используемой фичи в компиляторах.

CU>порядок вычисления и поток выполнения не определен, то есть невозможно понять в каком порядке компилятор обработает их и невозможно отладить это.
Определён Это ещё и ленивый функциональный язык в плане получения результата — пока явно не запросишь, вычисления не будут произведены.

CU>К тому же функциональные языки чтобы называться таковыми должны уметь выполнять типичные алгоритмы, можно ли на шаблонах построить дерево, сбалансировать, преобразовать в другой вид?
Да без проблем. Дерево можно задать как набор lisp/scheme'вских cons'ов, а потом выполнить неразрушающее преобразование над ним.

CU>Функции в этих языках первоклассные сущности, в шаблонах же нет функций как таковых преобразующих данные из одного в другой.
Их заменяют типы, которые преобразуют переданные типы и тем самым ведут себя как функции.

CU>Поэтому вряд ли их можно назвать чисто функциональным языком, это более надстройка во время компиляции для настройки системы типов, которую пытаются растянут чтобы получить некое метапрограммирование в терминах типов.
Вполне можно назвать, и называют — см. аргументы выше.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, CodingUnit, Вы писали:

А>В шаблон можно передать шаблон. Шаблон есть первоклассный объект времени компиляции, аналогично функции в чисто функциональном. Для полноты достаточно альтернативы и рекурсии.
Шаблон это не тоже что и функция, и то что он первоклассный это не говорит о том что это делает язык функциональным, как это принято понимать, типичный алгоритм не вызвать в шаблоне запустив его из другого шаблона.

А>С отладкой проблемы. Но тут Просто никто не писал отладку. Представьте если бы в немерли было нельзя останавливать во время компиляции
это и говорит о том что шаблоны не спроектированы чтобы использоваться как полноценная система метапрограммирования, а более допущение, которое пытаются использовать

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

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

Здравствуйте, CodingUnit, Вы писали:

CU>Шаблон это не тоже что и функция, и то что он первоклассный это не говорит о том что это делает язык функциональным, как это принято понимать, типичный алгоритм не вызвать в шаблоне запустив его из другого шаблона.
Шаблон представляет собой чистую функцию, позволяющие запускать другие алгоритмы (написанные на шаблонах) из другого шаблона.

CU>это и говорит о том что шаблоны не спроектированы чтобы использоваться как полноценная система метапрограммирования, а более допущение, которое пытаются использовать
Никто не спорит с этим, а вот со следующим:

CU>Может кому то все же очень хочется назвать этот язык шаблонов функциональным, ну пожалуйста называйте и используйте, мы же говорим не о терминах, а чем плохи шаблоны по сравнению с макросами Н, я эту разницу показал.
Спор разгорелся как раз из-за терминов — странного определения тьюринг-полноты.
Никто в ветке не умаляет значимости макросов Nemerle (возможность общаться с системой прямо во время компиляции шикарна) и не хвалит шаблоны плюсов, но оценивать тьюринг-полноту по чтению/записи файлов это же не дело

Здравствуйте, Alexey F, Вы писали:

AF>Здравствуйте, CodingUnit, Вы писали:

CU>>Довольно странное определение, к чисто функциональным языкам относят языки неиспользующими деструктивные модификации, но в шаблонах С++ нет переменных как таковых, есть только типы и константы
AF>Операции над типами и константами недеструктивны по определению Кто-то (remark? Сложно найти, когда форум отвечает на часть запросов фразой "Language color pattern source xml stream is not valid") на forum/cpp находил способ запоминать кое-какое состояние между вызовами шаблонов, но в результате пришли к выводу, что этот спецэффект возник из-за недочёта реализации используемой фичи в компиляторах.

CU>>К тому же функциональные языки чтобы называться таковыми должны уметь выполнять типичные алгоритмы, можно ли на шаблонах построить дерево, сбалансировать, преобразовать в другой вид?
AF>Да без проблем. Дерево можно задать как набор lisp/scheme'вских cons'ов, а потом выполнить неразрушающее преобразование над ним.

Вот это не вполне понятно как можно произвести любое преобразование над любым деревом в шаблоне, например балансировку, поясните примером

CU>>Функции в этих языках первоклассные сущности, в шаблонах же нет функций как таковых преобразующих данные из одного в другой.
AF>Их заменяют типы, которые преобразуют переданные типы и тем самым ведут себя как функции.
А как запустить шаблон из шаблона, с новыми аргументами?

AF>Вполне можно назвать, и называют — см. аргументы выше.
Но все же говоря о теме, мы говорим чем они плохи по сравнению с Н, если и попытаться поставить их в разряд чисто функциональных языков, но не дает никакого преимущества

Здравствуйте, Alexey F, Вы писали:

AF>Шаблон представляет собой чистую функцию, позволяющие запускать другие алгоритмы (написанные на шаблонах) из другого шаблона.
С этим очень много ограничений, например помоему невозможно вызвать шаблон T с параметрами шаблона T<T2, T3>, ведь T еще не определен, тут придется изловчаться с инстанционированием

AF>Спор разгорелся как раз из-за терминов — странного определения тьюринг-полноты.
AF>Никто в ветке не умаляет значимости макросов Nemerle (возможность общаться с системой прямо во время компиляции шикарна) и не хвалит шаблоны плюсов, но оценивать тьюринг-полноту по чтению/записи файлов это же не дело

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

Здравствуйте, Аноним, Вы писали:

А>Просто писать после императивного в чисто функциональном тяжело. Не понимаешь почему надо писать кучу кода вместо обычного императива. У вас есть опыт написания на чисто функциональном?
Не знаю как на чистом, но на Haskell вместо кучи императивного кода приходится писать несколько строчек функционального.

Здравствуйте, CodingUnit, Вы писали:

CU>Может я не так понимал тьюринг полноту, я просто сразу вижу что на С++ я могу написать любую программу, а на шаблонах нет. Действительно вопрос вроде ясен, если даже и оставить все эти термины за шаблонами.
А спор был только из-за термина тьюринг-полноты. Шаблоны и brainfuck у нас так, под руку подвернулись . (Возможно, я повторяюсь, пару раз форум ошибку выплёвывал)

CU>С этим очень много ограничений, например помоему невозможно вызвать шаблон T с параметрами шаблона T<T2, T3>, ведь T еще не определен, тут придется изловчаться с инстанционированием
Можно:

template<class T, class U>
struct Node {
    typedef T head;
    typedef U tail;
};

template<class T, class U>
struct Test2 {
    typedef Node<T, U> result;
};

template<template<class, class> class T, class U, class Z>
struct Test {
    typedef typename T<U, Z>::result result;
};


typedef Test<Test2, int, double>::result A;

Можно свести к синтаксису T::Func<A, B>, если изменить Test2.

Здравствуйте, WolfHound, Вы писали:

WH>Скажешь это не программа на чистом функциональном языке?
WH>http://www.rsdn.ru/forum/philosophy/1910243.1.aspx

Автор: WolfHound
Дата: 22.05.06

WH>Там есть функция MergeSort которая принимает список и предикат Int2TypeLess.

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

Здравствуйте, Аноним, Вы писали:

А>собственно какие возражения против шаблонов? Чем они отличаются от функциональнозапрограммированых макросов

попробуйте написать парсер с#?
посмотрите на сложность кода?
сравните как это сделано в Н. через год расскажите

Здравствуйте, catbert, Вы писали:

C>Что-то мне кажется, что сделать шаблоны из макросов Nemerle — не запросто.

Никаких проблем с этим нет. Проблема в том, что по юзабельности он будет таким же убогим как и шаблоны. Никакого интелисенса, мало-понятные сообщения об ошибках. И почти никакого толку.

В общем, и целом дженерики решают проблему обобщенного программирования. А шаблоны С++ интересны, в основном, своими возможностями метапрограммирования. Но в этой области макросам нет равных. И уж эмулировать МП на шаблонах созданных на базе макросов просто глупо.

Здравствуйте, para, Вы писали:

P>Здравствуйте, Аноним, Вы писали:

А>>собственно какие возражения против шаблонов? Чем они отличаются от функциональнозапрограммированых макросов

P>попробуйте написать парсер с#?
P>посмотрите на сложность кода?
P>сравните как это сделано в Н. через год расскажите

вообще то сделали на спирит. Правда дефакто не более чем демонстрация принципиальной возможности

Здравствуйте, CodingUnit, Вы писали:

CU>Так о каких таких шаблонах идет речь, если не о С++ и где там чисто функциональный язык и хвостовая рекурсия?

Пойди и почитай теорию.

ЗЫ

Ты не о том споришь. Тюринг полнота ни разу не достаточна для решения конкретных задач.

Здравствуйте, Alexey F, Вы писали:

AF>Никто в ветке не умаляет значимости макросов Nemerle (возможность общаться с системой прямо во время компиляции шикарна) и не хвалит шаблоны плюсов, но оценивать тьюринг-полноту по чтению/записи файлов это же не дело

Вообще-то умаляет и хвалит. Но с тюринг-полнотой CodingUnit действительно путает. Это распространенное заблуждение — подмена понятия отсутствие ограничений в доступе к данным и полноту по тьюрингу.

Здравствуйте, WolfHound, Вы писали:

WH>Если у меня вдруг появится настроение я даже машину Тьюринга на шаблонах могу изобразить.

Это вряд ли. Что будешь в качестве непрерывной ленты использовать?

Здравствуйте, Аноним, Вы писали:

А>вообще то сделали на спирит. Правда дефакто не более чем демонстрация принципиальной возможности

Демонстрация отличается от реальной реализации примерно так же как теория от практики .

Ради прикола сравни говногод который у них получился с вот этим. И, как говорится, почувствуйте разницу. А когда заработает ParserGenerator, как следует, разговоры о Спирите даже смешными не будут казаться. Шутка ли? Полностью декларативный парсер с возможностью динамического расширения да еще и рвущий лучше генераторы парсеров написанных на С++ по скорости. Примерчик использования.

Здравствуйте, CodingUnit, Вы писали:

CU>Так о каких таких шаблонах идет речь, если не о С++ и где там чисто функциональный язык и хвостовая рекурсия?

Если на самом деле хочется сравнить мощность шаблонов и макросов то лучше посмотреть на лучшую по моему на данный
момент их реализацию, то есть на язык D:

http://www.d-programming-language.org/template.html
http://www.d-programming-language.org/template-mixin.html
http://www.d-programming-language.org/function.html#interpretation

Здравствуйте, CodingUnit, Вы писали:

CU>Здравствуйте, Alexey F, Вы писали:

AF>>Здравствуйте, CodingUnit, Вы писали:

AF>>Итааак...

>>>А как запустить шаблон из шаблона, с новыми аргументами?
AF>>Это я уже показал: http://rsdn.ru/forum/nemerle/4603395.1.aspx

Автор: Alexey F
Дата: 04.02.12

CU>Да, алгоритм вам удался, получаются многие алгоритмы на шаблонах, но до каких же извращений вы дошли ребята. Я хоть и программлю на С++ по работе, но мне все же больше интересней работа с Н во время компиляции и перевод его в АСТ С++ и генерация кода. Так можно делать больше вещей во время компиляции и генерировать что нужно.

Достаточно безумная мысль так как немерле слишком завязан на нет и придется перетаскивать кучу библиотек нет что делает вашу работу сложной если не реальной.

Здравствуйте, VladD2, Вы писали:

WH>>Если у меня вдруг появится настроение я даже машину Тьюринга на шаблонах могу изобразить.
VD>Это вряд ли. Что будешь в качестве непрерывной ленты использовать?
Не забывай с кем разговариваешь...

template<class H, class T>
struct TypeList
{
    typedef H Head;
    typedef T Tail;
};
struct NullType{};

template<class LeftItemsArg, class ItemArg, class RightItemsArg>
struct Tape
{
    typedef LeftItemsArg  LeftItems;
    typedef ItemArg       Item;
    typedef RightItemsArg RightItems;

    template<class NewItemArg>
    struct Replace
    {
        typedef Tape<LeftItems, NewItemArg, RightItems> Value;
    };
};

template<class ItemsArg, class DefaultItemArg>
struct PopItem;

template<class ItemArg, class TailArg, class DefaultItemArg>
struct PopItem<TypeList<ItemArg, TailArg>, DefaultItemArg>
{
    typedef ItemArg Item;
    typedef TailArg Items;
};

template<class DefaultItemArg>
struct PopItem<NullType, DefaultItemArg>
{
    typedef DefaultItemArg Item;
    typedef NullType       Items;
};

template<class TapeArg, class DefaultItemArg>
struct MoveLeft
{
    typedef PopItem<typename TapeArg::LeftItems, DefaultItemArg> NewLeftItems;
    typedef Tape<typename NewLeftItems::Items, typename NewLeftItems::Item, TypeList<typename TapeArg::Item, typename TapeArg::RightItems> > Value;
};

template<class TapeArg, class DefaultItemArg>
struct MoveRight
{
    typedef PopItem<typename TapeArg::RightItems, DefaultItemArg> NewRightItems;
    typedef Tape<TypeList<typename TapeArg::Item, typename TapeArg::LeftItems>, typename NewRightItems::Item, typename NewRightItems::Items> Value;
};

typedef Tape<NullType, int, NullType> Tape1;
typedef MoveRight<Tape1, int>::Value Tape2;
typedef Tape2::Replace<char>::Value Tape3;
typedef MoveRight<Tape3, int>::Value Tape4;
typedef MoveLeft <Tape4, int>::Value Tape5;
typedef MoveLeft <Tape5, int>::Value Tape6;

int main(int argc, char* argv[])
{
    std::cout << typeid(Tape1).name() << std::endl;
    std::cout << typeid(Tape2).name() << std::endl;
    std::cout << typeid(Tape3).name() << std::endl;
    std::cout << typeid(Tape4).name() << std::endl;
    std::cout << typeid(Tape5).name() << std::endl;
    std::cout << typeid(Tape6).name() << std::endl;
    return 0;
}

Печатает

struct Tape<struct NullType,int,struct NullType>
struct Tape<struct TypeList<int,struct NullType>,int,struct NullType>
struct Tape<struct TypeList<int,struct NullType>,char,struct NullType>
struct Tape<struct TypeList<char,struct TypeList<int,struct NullType> >,int,struct NullType>
struct Tape<struct TypeList<int,struct NullType>,char,struct TypeList<int,struct NullType> >
struct Tape<struct NullType,int,struct TypeList<char,struct TypeList<int,struct NullType> > >

Здравствуйте, Аноним, Вы писали:

А>Достаточно безумная мысль так как немерле слишком завязан на нет и придется перетаскивать кучу библиотек нет что делает вашу работу сложной если не реальной.

Смотря что я хочу сделать, если я хочу на базе некоего ДСЛ, сделать код автомата на С++, или еще что то упростить во время компиляции, то могу весь разбор сделать на Немерле а на С++ сделать генерацию, АСТ конечно может вместить только базовые вещи, что в них общие, match будет цепочкой if, а код должен будет обращаться к типам из stl.

Здравствуйте, <Аноним>, Вы писали:

А>Достаточно безумная мысль так как немерле слишком завязан на нет и придется перетаскивать кучу библиотек нет что делает вашу работу сложной если не реальной.
Для Н1 да.
Для Н2 это будет штатный режим работы.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, <Аноним>, Вы писали:

А>>Достаточно безумная мысль так как немерле слишком завязан на нет и придется перетаскивать кучу библиотек нет что делает вашу работу сложной если не реальной.
WH>Для Н1 да.
WH>Для Н2 это будет штатный режим работы.

Макросы стандартной библиотеки немерли не будут использовать стандартную библиотеку нет? Такое решение принято?

Здравствуйте, WolfHound, Вы писали:

WH>Не забывай с кем разговариваешь...
Вот так еще лучше.
Убрал элемент, которым заполнена лента по умолчанию в саму ленту.
Сделал объектно-ориентированный интерфейс ленте.
Добавил нормализацию ленты. Теперь если текущий элемент равен элементу по умолчанию и список пуст, то список остается пустым.
Таким образом, типы получаются короче. И что важно две ленты можно легко проверить на равенство.

template<class H, class T>
struct TypeList
{
    typedef H Head;
    typedef T Tail;
};
struct NullType{};

template<class TapeArg>
struct MoveLeftImpl;
template<class TapeArg>
struct MoveRightImpl;

template<class LeftItemsArg, class ItemArg, class RightItemsArg, class DefaultArg>
struct Tape
{
    typedef LeftItemsArg  LeftItems;
    typedef ItemArg       Item;
    typedef RightItemsArg RightItems;
    typedef DefaultArg    Default;
    typedef Tape<LeftItemsArg, ItemArg, RightItemsArg, DefaultArg> This;

    template<class NewItemArg>
    struct Replace
    {
        typedef Tape<LeftItems, NewItemArg, RightItems, Default> Value;
    };

    typedef typename MoveLeftImpl<This>::Value  MoveLeft;
    typedef typename MoveRightImpl<This>::Value MoveRight;
};

template<class ItemsArg, class DefaultItemArg>
struct PopItem;

template<class ItemArg, class TailArg, class DefaultItemArg>
struct PopItem<TypeList<ItemArg, TailArg>, DefaultItemArg>
{
    typedef ItemArg Item;
    typedef TailArg Items;
};

template<class DefaultItemArg>
struct PopItem<NullType, DefaultItemArg>
{
    typedef DefaultItemArg Item;
    typedef NullType       Items;
};

template<class ItemArg, class ItemsArg, class DefaultItemArg>
struct PushItem
{
    typedef TypeList<ItemArg, ItemsArg> Value;
};

template<class ItemArg>
struct PushItem<ItemArg, NullType, ItemArg>
{
    typedef NullType Value;
};

template<class TapeArg>
struct MoveLeftImpl
{
    typedef PopItem<typename TapeArg::LeftItems, typename TapeArg::Default> NewLeftItems;
    typedef Tape
        < typename NewLeftItems::Items
        , typename NewLeftItems::Item
        , typename PushItem<typename TapeArg::Item, typename TapeArg::RightItems, typename TapeArg::Default>::Value
        , typename TapeArg::Default
        > Value;
};

template<class TapeArg>
struct MoveRightImpl
{
    typedef PopItem<typename TapeArg::RightItems, typename TapeArg::Default> NewRightItems;
    typedef Tape
        < typename PushItem<typename TapeArg::Item, typename TapeArg::LeftItems, typename TapeArg::Default>::Value
        , typename NewRightItems::Item
        , typename NewRightItems::Items
        , typename TapeArg::Default
        > Value;
};

typedef Tape<NullType, int, NullType, int> Tape1;
typedef Tape1::MoveRight Tape2;
typedef Tape2::Replace<char>::Value Tape3;
typedef Tape3::MoveRight Tape4;
typedef Tape4::MoveRight Tape5;
typedef Tape5::MoveLeft Tape6;
typedef Tape6::MoveLeft Tape7;
typedef Tape7::MoveLeft Tape8;
typedef Tape8::MoveRight Tape9;

int main(int argc, char* argv[])
{
    std::cout << typeid(Tape1).name() << std::endl;
    std::cout << typeid(Tape2).name() << std::endl;
    std::cout << typeid(Tape3).name() << std::endl;
    std::cout << typeid(Tape4).name() << std::endl;
    std::cout << typeid(Tape5).name() << std::endl;
    std::cout << typeid(Tape6).name() << std::endl;
    std::cout << typeid(Tape7).name() << std::endl;
    std::cout << typeid(Tape8).name() << std::endl;
    std::cout << typeid(Tape9).name() << std::endl;
    return 0;
}

struct Tape<struct NullType,int,struct NullType,int>
struct Tape<struct NullType,int,struct NullType,int>
struct Tape<struct NullType,char,struct NullType,int>
struct Tape<struct TypeList<char,struct NullType>,int,struct NullType,int>
struct Tape<struct TypeList<int,struct TypeList<char,struct NullType> >,int,struct NullType,int>
struct Tape<struct TypeList<char,struct NullType>,int,struct NullType,int>
struct Tape<struct NullType,char,struct NullType,int>
struct Tape<struct NullType,int,struct TypeList<char,struct NullType>,int>
struct Tape<struct NullType,char,struct NullType,int>

Здравствуйте, <Аноним>, Вы писали:

А>Макросы стандартной библиотеки немерли не будут использовать стандартную библиотеку нет? Такое решение принято?
Н2 это не язык в привычном понимании этого слова.
Это скорее родственник MPS, XText итп но несравнимо более технологичный.
В поставке, конечно же, будет куча прикладных языков. В том числе язык являющейся надмножеством Н1.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, <Аноним>, Вы писали:

А>>Макросы стандартной библиотеки немерли не будут использовать стандартную библиотеку нет? Такое решение принято?
WH>Н2 это не язык в привычном понимании этого слова.
WH>Это скорее родственник MPS, XText итп но несравнимо более технологичный.
WH>В поставке, конечно же, будет куча прикладных языков. В том числе язык являющейся надмножеством Н1.

Вы не ответили на вопрос. Вопрос в том на сколько н2 привязана к нет. Как я понимаю жестко. Переделать генерацию кода это четверть работы.

Здравствуйте, <Аноним>, Вы писали:

А>Вы не ответили на вопрос. Вопрос в том на сколько н2 привязана к нет. Как я понимаю жестко. Переделать генерацию кода это четверть работы.
Первые версии будут работать под .НЕТ. Но смогут генерировать код подо что угодно.
Те .НЕТ будет нужен только на машине разработчика и билд серверах.
В будущем планируется полностью отвязать его от платформы.
Благо ядру привязка к платформе не нужна.

Здравствуйте, Alexey F, Вы писали:

AF>Итааак...

Это какойто ахтунг. Да и вообще все примеры шаблонов в C++ в этом топике какой-то ахтунг.
Сравнимо с ним по вырвиглазности наверно использование XSLT 1.0 для банальных распиливаний строк и сортировок всяческих. Причем если в XSLT можно подсунуть собственные расширения (в .NET или Java), реализующие необходимые примитивы (например для string.Split и Regex.Match), то в C++ ных шаблонах ничего подобного сделать нельзя и они оставляют тебя наедине с какой-то невнятной кашей уголков и ключевых слов.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, hardcase, Вы писали:

H>>Это какойто ахтунг. Да и вообще все примеры шаблонов в C++ в этом топике какой-то ахтунг.
WH>Я тебе скажу как краевед: Все примеры шаблонов С++ выходящие за приделы обобщенных контейнеров полный ахтунг.

Если бы скорость компиляции шаблонов значительно подняли то появились бы аналоги for в немерли и удобство программирования было бы конечно не немерли но и не то что сейчас. Но это никто не делает так как все шаблоны делаются простыми и значит такая оптимизация не нужна. Тут проблема курицы и яйца.

Здравствуйте, hardcase, Вы писали:

H>Это какойто ахтунг. Да и вообще все примеры шаблонов в C++ в этом топике какой-то ахтунг.

Угу.
В D правда гораздо лучше, большая часть глупых недостатков исправлены, плюс такая вещь как
CTFE многое что реализуется шаблонами в C++ делать обычными функциями в D.

Здравствуйте, para, Вы писали:

P>Здравствуйте, Аноним, Вы писали:

А>>>>Достаточно безумная мысль так как немерле слишком завязан на нет и придется перетаскивать кучу библиотек нет что делает вашу работу сложной если не реальной.

WH>>>Для Н2 это будет штатный режим работы.

А>>Макросы стандартной библиотеки немерли не будут использовать стандартную библиотеку нет? Такое решение принято?

P>в данном случае не столько важно от чего зависят макросы.

P>важно то, что СГЕНЕРИРОВАННЫЙ ими код может НЕ ЗАВИСЕТЬ ни от чего

супер. РЕАЛЬНО В ЭТО ВЕРИШЬ?

Здравствуйте, <Аноним>, Вы писали:

P>>важно то, что СГЕНЕРИРОВАННЫЙ ими код может НЕ ЗАВИСЕТЬ ни от чего
А>супер. РЕАЛЬНО В ЭТО ВЕРИШЬ?
Причем тут вера?
Код, который генерируют чуть менее чем все компиляторы, не зависит от самого компилятора.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, <Аноним>, Вы писали:

P>>>важно то, что СГЕНЕРИРОВАННЫЙ ими код может НЕ ЗАВИСЕТЬ ни от чего
А>>супер. РЕАЛЬНО В ЭТО ВЕРИШЬ?
WH>Причем тут вера?
WH>Код, который генерируют чуть менее чем все компиляторы, не зависит от самого компилятора.

Но зависит от стандартной библиотеки, которая зависит от нет.

Здравствуйте, <Аноним>, Вы писали:

А>Но зависит от стандартной библиотеки, которая зависит от нет.
Ты серьезно или прикалываешься?
Скажи что мешает компилятору написанному на .НЕТ генерировать код не под .НЕТ?

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, <Аноним>, Вы писали:

А>>Но зависит от стандартной библиотеки, которая зависит от нет.
WH>Ты серьезно или прикалываешься?
WH>Скажи что мешает компилятору написанному на .НЕТ генерировать код не под .НЕТ?

И как отлаживать этот код?

Здравствуйте, Аноним, Вы писали:

А>И как отлаживать этот код?

Скажем, то с чего начали, если я генерю С++ текстовый код для микроконтроллера, то я буду отлаживать на самом микроконтроллере, или на той платформе для которой я его генерил. С этим проблем быть не должно, здесь Н поможет только как конвертер и первичная основа для преобразования нужного мне ДСЛ или другой трансформации. Хотя здесь действительно нет ограничений и связи с Н, можно и ассемблерные инструкции генерить если нужно, все компиляторы создавались на других языках и интерпретаторах, первый Фортран вообще люди выступали в роли первичного компилятора, но потом связи с прежней платформой не осталось.

Здравствуйте, CodingUnit, Вы писали:

CU>Скажем, то с чего начали, если я генерю С++ текстовый код для микроконтроллера, то я буду отлаживать на самом микроконтроллере, или на той платформе для которой я его генерил. С этим проблем быть не должно, здесь Н поможет только как конвертер и первичная основа для преобразования нужного мне ДСЛ или другой трансформации. Хотя здесь действительно нет ограничений и связи с Н, можно и ассемблерные инструкции генерить если нужно, все компиляторы создавались на других языках и интерпретаторах, первый Фортран вообще люди выступали в роли первичного компилятора, но потом связи с прежней платформой не осталось.

Тут http://felix-lang.org/ (https://github.com/felix-lang/felix) целый язык генерирующий C++ и во многом не уступающий немерле:

Features:

* generates highly optimised ISO C++
* advanced resource manager organises compilation and linkage
* often runs faster than C
* glueless binding to C and C++ libraries
* lightweight threads with channels
* asynchronous network I/O
* thread safe garbage collection
* strictly statically typed
* overloading
* first order parametric polymorphism
* polymorphism with constraints
* multitype Haskell style type classes
* type classes with real semantic specification
* semantics can be checked by theorem provers
* strong functional subsystem
* pattern matching
* first class function, sum, and product types
* Tre based regexp processing built in

а по некоторым фичам и Хаскель переплевывает.

Здравствуйте, WolfHound, Вы писали:

WH>>>Если у меня вдруг появится настроение я даже машину Тьюринга на шаблонах могу изобразить.
VD>>Это вряд ли. Что будешь в качестве непрерывной ленты использовать?
WH>Не забывай с кем разговариваешь...

На вопрос то не хочешь ответить?

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

Здравствуйте, FR, Вы писали:

FR>Тут http://felix-lang.org/ (https://github.com/felix-lang/felix) целый язык генерирующий C++ и во многом не уступающий немерле:

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

FR>Тут http://felix-lang.org/ (https://github.com/felix-lang/felix) целый язык генерирующий C++ и во многом не уступающий немерле:

AST должен быть очень близкий, значит можно дернуть оттуда генератор С++

Здравствуйте, CodingUnit, Вы писали:

CU>Это интересно для некоторых задач, только больно тяжело читать документацию, сайт так сделан, не могу найти нормального туториала.

Да с документацией там туговато, сам вот только-только начал разбираться с этим языком.
Примеры тут http://felix-lang.org/$/usr/local/lib/felix/felix-latest/doc/Tutorial.fdoc

Здравствуйте, _Claus_, Вы писали:

_C_>AST должен быть очень близкий, значит можно дернуть оттуда генератор С++

Локальный код возможно, но глобально вряд-ли языки слишком разные например феликс в отличии от немерле поддерживает не NET ОО а type class хаскелеобразные, да и в остальном наверняка куча различий.

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, _Claus_, Вы писали:

_C_>>AST должен быть очень близкий, значит можно дернуть оттуда генератор С++

FR>Локальный код возможно, но глобально вряд-ли языки слишком разные например феликс в отличии от немерле поддерживает не NET ОО а type class хаскелеобразные, да и в остальном наверняка куча различий.

тут кто то говорил о метаязыке типов....

Здравствуйте, Аноним, Вы писали:

А>супер. РЕАЛЬНО В ЭТО ВЕРИШЬ?

поробуйте Н и вы сами поверите...

пример на псевдокоде (извини под рукой нет компилятора) главное смотри идею:

macro CompileAsC(sources:PExpr)
{  
  def text = Analize(sources);         // ГЛУБОКИЙ АНАЛИЗ АСТ. в данном примере просто проброс строки

  File.WriteAllText("tmp.c", text);    // генерация кода конечно должна
  ShellExecute("gcc tmp.c -o res.exe") // быть покрасивее, но для примера
}

void main() 
{
  CompileAsC("prinf(\"hello world\")");
}

res.exe — результат(побочный) применения макроса логически зависит от исходников
но физически НЕ зависит от .Net

Здравствуйте, para, Вы писали:

более показательно примерно так:

macro CompileAsC(ast:PExpr)
{  
  def text = Analize(ast);             // ГЛУБОКИЙ АНАЛИЗ АСТ. в данном примере просто проброс строки

  File.WriteAllText("tmp.c", text);    // генерация кода конечно должна
  ShellExecute("gcc tmp.c -o res.exe") // быть покрасивее, но для примера

  <[]>
}

Analize(ast:PExpr) : string
{
| <[Console.WriteLine($str)]> => $"prinf($str)";
| _ => Message.Error();
}

void main() 
{
  CompileAsC(Console.WriteLine("hello world"));
}

отличается от шаблонов наличием Analize(ast:PExpr)

Здравствуйте, para, Вы писали:

У меня такое чувство что мы говорим о разных вещах.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, para, Вы писали:

А>У меня такое чувство что мы говорим о разных вещах.

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

Здравствуйте, Аноним, Вы писали:

VD>>Пойми есть огромная разница между полнотой по тьюрингу некоторой машины возможностью на ней воспроизвести саму эту машу в исходом описании.

А>нет разницы. Полнота по тьюрингу это возможность воспроизвести машину тьюринга.

Это, мягко говоря, заблуждение. Машину Тьринга вообще невозможно воспроизвести на компьютерах, так как они не обладают безграничными ресурсами которые нужные для реализации той самой бесконечной ленты. Машина Тьринга — это абстракция. И для каждого алгоритма она будет своя. Так что ее можно имитировать с некоторыми ограничениями, но невозможно воспроизвести.

Полнота по Тьюрингу означает эквивалентность ей по вычислительным возможностям. Или, если не заумствовать, возможность реализации любого вычислительного алгоритма который может быть гипотетически реализован с помощью машины Тьюринга (конкретной).

Здравствуйте, VladD2, Вы писали:

WH>>Не забывай с кем разговариваешь...
VD>На вопрос то не хочешь ответить?
Так я тебе реализацию этой самой ленты показал.

VD>Пойми есть огромная разница между полнотой по тьюрингу некоторой машины возможностью на ней воспроизвести саму эту машу в исходом описании.
Разницы нет.
Если удалось воспроизвести машину Тьюринга, то полнота по Тьюрингу доказана.
Ибо если работает машина Тьюринга то на ней можно запустить любой алгоритм, написанный для машины Тьюринга.

Конечность памяти в реальных устройствах во внимание не принимается. Просто по тому, что устройств с бесконечной памятью нет.

Здравствуйте, <Аноним>, Вы писали:

WH>>Скажи что мешает компилятору написанному на .НЕТ генерировать код не под .НЕТ?
А>И как отлаживать этот код?
Мда... и что же мне помешает сгенерировать отладочную информацию?

Здравствуйте, Аноним, Вы писали:

А>Достаточно безумная мысль так как немерле слишком завязан на нет и придется перетаскивать кучу библиотек нет что делает вашу работу сложной если не реальной.

Мысль весьма здравая, если не пытаться сделать универсальный транслятор. Если рассматривать частные случаи, то особых проблем в генерации кода нет. Можно хоть С++, хоть жабаскрипт генерировать.

Здравствуйте, WolfHound, Вы писали:

WH>Так я тебе реализацию этой самой ленты показал.

Она не бесконечна.

WH>Конечность памяти в реальных устройствах во внимание не принимается.

Тогда твое решение тоже не принимается как машина тьюринга. Это некоторое приближение. Да и машины тьюрига универсальной не бывает. Она как конечный автомат, для каждого алгоритма новая.

Здравствуйте, FR, Вы писали:

FR>В D правда гораздо лучше, большая часть глупых недостатков исправлены, плюс такая вещь как
FR>CTFE многое что реализуется шаблонами в C++ делать обычными функциями в D.

Вот это вот CTFE — это и есть попытка делать то, что немерл делает просто и со вкусом — выполнять произвольный код на основном языке во время компиляции. В D на CTFE налакается куча ограничений и они мало что могут. В Немерле ограничений нет и в них можно все что можно сделать на самом языке.

Внимание, вопрос! На фиге козе баяннужны рекурсивные шаблоны и вычисления на них, если есть полноценные ничем не ограниченные, быстрые вычисления на самом немерле?

А D, да. Шаблоны внем не плохие. Переменное количество параметров типов вообще рулит. Правда оно и в новом С++ должно быть, вроде бы.

Здравствуйте, Аноним, Вы писали:

P>>важно то, что СГЕНЕРИРОВАННЫЙ ими код может НЕ ЗАВИСЕТЬ ни от чего

А>супер. РЕАЛЬНО В ЭТО ВЕРИШЬ?

А что же не верить в реальность то?

Вот пример генерации жабаскрипта на немерле. Какие там проблемы с зависимостью? Полученный жабаскрипт работает без малейших проблем.

Здравствуйте, FR, Вы писали:

FR>Тут http://felix-lang.org/ (https://github.com/felix-lang/felix) целый язык генерирующий C++ и во многом не уступающий немерле:

Я знаю один язык которому даже генерировать ничего не надо — С++ называется. И что с того? Макросов то в нем нет, а МП ограничено извращениями на шаблонах. В этом ваше Феликсе, скорее всего тоже самое будет. Только для него еще ни IDE, ни поддержки не будет.

Так что ты нам лучше ссылки на языки давай, а описывай, что в этих языках интересного. Глядишь что-нить полезное найдем.

Здравствуйте, Аноним, Вы писали:

А>нет разницы. Полнота по тьюрингу это возможность воспроизвести машину тьюринга.

http://ru.wikipedia.org/wiki/Машина_Тьюринга

Есть программы для обычных компьютеров, имитирующие работу машины Тьюринга. Но следует отметить, что данная имитация неполная, так как в машине Тьюринга присутствует абстрактная бесконечная лента. Бесконечную ленту с данными невозможно в полной мере имитировать на компьютере с конечной памятью (суммарная память компьютера — оперативная память, жёсткие диски, различные внешние носители данных, регистры и кэш процессора и др. — может быть очень большой, но, тем не менее, всегда конечна).

Здравствуйте, WolfHound, Вы писали:

VD>>Она не бесконечна.
WH>Она бесконечна.
WH>Единственное что ограничивает ее длинну это конечность памяти компьютера.
WH>Но если принять это во внимание, то тогда придется признать, что не существует полных по Тьюрингу языков.

Нет придется просто понять, что полнота по тьюрингу не тоже самое, что реальная реализация машины тьюринга, а просто умозаключение позволяющее сделать вывод о вычислительных возможностях.

Здравствуйте, VladD2, Вы писали:

VD>Нет придется просто понять, что полнота по тьюрингу не тоже самое, что реальная реализация машины тьюринга, а просто умозаключение позволяющее сделать вывод о вычислительных возможностях.
Ох. Один из способов доказать полноту вычислителя по Тьюрингу это написать интерпретатор машины Тьюринга для данного вычислителя.