Помню, как в начале 90-х все пищали: "ах, шаблоны — это так круто и удобно, попрощаемся же навсегда с macro hell". Теперь мы уже много лет имеем template hell, но настолько привыкли считать, что шаблоны — это круто, что как-то даже стыдно думать об альтернативах. А ведь на обработку сотен-тысяч навороченных макросов требовались ничтожные, по нынешним временам, ресурсы, но сейчас обработка сравнимого количества шаблонов требует многократно бОльших ресурсов, а отлаживать их нередко бывает сложнее, чем макросы.
При этом, изрядная доля macro hell происходила лишь от того, что обработка исходника была искусственно разделена на препроцессирование и компиляцию. В начале 70-х это еще можно было как-то оправдать нехваткой ресурсов, хотя убогие возможности сишного препроцессора вряд ли могли заметно утяжелить компилятор. Имей компилятор возможность хотя бы просто выдать в сообщении об ошибке как исходную конструкцию, так и результат ее обработки макропроцессором, это свело бы на нет бОльшую часть проблем.
Современные компиляторы используют предкомпиляцию шаблонов, но она, по сути, не столько ускоряет компиляцию вообще, сколько снижает тормоза, создаваемые множеством многоуровневых шаблонных конструкций. И все равно оптимизатору приходится как-то систематизировать функции, чтобы объединить те, что отличаются только типами, но при этом не оформлены ни в шаблоны, ни в перегрузки.
Считается, что функциональный стиль использования шаблонов — это благо, но многие ли способны быстро разобраться в иерархии и взаимодействии шаблонов в какой-нибудь Boost? В конце концов, какая часть математиков интуитивно воспринимает факториал, как отображение множества целых чисел само на себя, или, на худой конец, как рекурсию, а не как последовательное (итеративное) произведение?
Вот будь вместо шаблонов приличный макропроцессор, в котором можно и параметры вызова разобрать, и циклические конструкции использовать, и за счет объединения с компилятором использовать в условиях типы, классы и их свойства — какие у шаблонов остались бы преимущества?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вот будь вместо шаблонов приличный макропроцессор, в котором можно и параметры вызова разобрать, и циклические конструкции использовать, и за счет объединения с компилятором использовать в условиях типы, классы и их свойства — какие у шаблонов остались бы преимущества?
Макросы в конечном итоге это просто подмена текста. Что там и на что подменяется компилятор проверять не обязан. А шаблоны это генератор типов, когда заранее известно, что работаем с конструкциями типов. Или те же константы тоже проходят оптимизацию, когда объявляются как константы, а не как макросы замены.
Я не углублялся в теорию компиляторов, но суть отказа от макросов при компиляции в оптимизации, которую проводит компилятор переводя конструкции языка в машинный код. Твоя же мысль звучит как давайте создадим более продвинутый генератор, который позволит учитывать ещё больше. Но где гарантия, что к примеру у тебя получится создать что-то лучше, а не те же шаблоны C++ только с перламутровыми пуговицами.
ЕМ>Теперь мы уже много лет имеем template hell, но настолько привыкли считать, что шаблоны — это круто, что как-то даже стыдно думать об альтернативах.
Альтернатива это берёшь те же шаблоны C++ и создаёшь на их основе свои библиотеки алгоритмов. Лично я считаю, что это проблема в расхождении видения понятий. Один программист видит вот так и пишет код вот так. А другой видит по другому и у него другой алгоритм и другие названия. Хотя решают они одну и ту же задачу.
Та же STL, ей можно принебречь, как и Boost. И создать свою библиотеку с нуля, которая будет выделять память как нужно конкретному программисту и многое другое вплоть до системных вызовов. Да, язык это позволяет, а то что многим удобно использовать стандартные контейнеры, алгоритмы и итераторы, то это совершенно другой вопрос.
Или вот, если тебе всё ещё нравится стиль Си, а макросы о которых мы говорим это именно они, и хотя они поддерживаются в C++ ими можно уже не пользоваться, так попробуй сделать на них что-нибудь адекватное. И первая проблема та же самая, это сложное создание своей собственной библиотеки алгоритмов, а использование чужой такой же hell как и везде, хоть в макросах, хоть в шаблонах.
Короче люди подсели на фреймворки и прочие чужие библиотеки алгоритмов, а всё потому, что написать что-то своё долго, сложно и дорого. А проблема фреймворков везде, и что они сложные через пень колоду, и что постоянно меняются. А что, выбор есть, фреймворк или свой велосипед. Лично я это с языками программирования не связываю.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вот будь вместо шаблонов приличный макропроцессор, в котором можно и параметры вызова разобрать, и циклические конструкции использовать, и за счет объединения с компилятором использовать в условиях типы, классы и их свойства — какие у шаблонов остались бы преимущества?
Трудно сказать, что было бы, если бы было то, чего нет.
В отладочной сборке по шаблонным функциям можно пошагать отладчиком. Ну или даже в не-отладочной, если оно не заинлайнилось.
С нынешними макро так не работает.
Непонятно, работало бы ли это с гипотетическим макро процессором.
Здравствуйте, velkin, Вы писали:
V>Макросы в конечном итоге это просто подмена текста. Что там и на что подменяется компилятор проверять не обязан.
Это примитивные, убогие сишные макросы, которые в C++ перетащили для совместимости, заранее объявив абсолютным злом, и постеснявшись хоть как-то улучшить.
V>А шаблоны это генератор типов, когда заранее известно, что работаем с конструкциями типов.
Идея макросов изначально состояла в генерации произвольного кода, в том числе и с параметрами типов. В Си макросы часто применялись именно для простой типизации, именно в этом их эффективно заменили шаблоны. Но большинство проблем макросов, повторю, возникало именно из-за разобщенности препроцессора и компилятора, когда управлять порождением можно было лишь набором абстрактных констант, и нельзя было использовать для этого свойства определенных к тому времени программных сущностей (переменных, функций, типов, классов и т.п.). Когда это пытались делать параллельно, конструкции быстро становились громоздкими, часто возникали ошибки синхронизации параллельных макросов друг с другом.
V>Я не углублялся в теорию компиляторов, но суть отказа от макросов при компиляции в оптимизации, которую проводит компилятор переводя конструкции языка в машинный код. Твоя же мысль звучит как давайте создадим более продвинутый генератор, который позволит учитывать ещё больше. Но где гарантия, что к примеру у тебя получится создать что-то лучше, а не те же шаблоны C++ только с перламутровыми пуговицами.
Мне хороший макропроцессор всегда виделся главным образом процедурным, а не функциональным. В таком стиле макрос напоминает функцию, которая выполняет операции над своими параметрами, результатом которых становится код, подлежащий обработке компилятором. То, что на шаблонах принято делать рекурсией (смысл и работа которой далеко не всегда очевидны) и не так давно реализованной распаковкой параметров, в макропроцессорах всегда делалось обычными циклическими конструкциями. То, что на шаблонах делается многоуровневыми (и опять же не всегда очевидными) вызовами предикатов, в нормальном макропроцессоре выглядело бы обычными условными конструкциями.
V>Альтернатива это берёшь те же шаблоны C++ и создаёшь на их основе свои библиотеки алгоритмов.
Ну, это не намного удобнее, чем делать на макросах в их существущем виде. Пока все просто и ортогонально, оно выглядит изящно и логично, но с ростом сложности библиотеки сложность записи растет очень быстро, и довольно скоро превращается в уродливую мешанину, половину которой составляют костыли.
V>Один программист видит вот так и пишет код вот так. А другой видит по другому и у него другой алгоритм и другие названия.
Это все верно, но у шаблонов главная проблема — в недостатке выразительных средств. Этакое прокрустово ложе, к которому периодически приделывают полочки, чтобы можно было ставить стакан или класть телефон, но лежать от этого удобнее не становится.
V>если тебе всё ещё нравится стиль Си, а макросы о которых мы говорим это именно они
Мне не нравится ни "стиль Си", ни "стиль C++" в их крайних вариантах. И то, и другое одинаково убого и уродливо, разве что последний позволяет больше спрятать под капотом до того момента, как капот сорвет давлением изнутри. А вот имей язык возможность определять макросы более широко, и порождать из них программный код более гибко — глядишь, и macro hell бы удалось изжить, и template hell вместо него не нажить.
V>хотя они поддерживаются в C++ ими можно уже не пользоваться, так попробуй сделать на них что-нибудь адекватное.
Так о том и речь, что на этом примитиве невозможно сделать ничего адекватного — как, например, и на простейшем бэйсике. Но из невозможности сделать что-то серьезное на простейшем бэйсике отнюдь не следует, что этого не сделать на любом процедурном ЯП, и спасение нужно искать исключительно в функциональных. Функциональный стиль хорош там, где сам алгоритм описан в функциональных терминах. Тащить его всюду лишь потому, что "круто и модно", не стоит.
V>люди подсели на фреймворки и прочие чужие библиотеки алгоритмов, а всё потому, что написать что-то своё долго, сложно и дорого.
Раньше "сложно и дорого" означало "нужны десять человек, год времени и миллион долларов", а в нынешнем мире программ-однодневок это нередко выливается в "нужен еще один человек, две недели и пять тысяч, но с фреймворком можем обойтись одним, сляпаем за неделю и две тысячи, все равно через полгода выкидывать".
Здравствуйте, Alexander G, Вы писали:
AG>В отладочной сборке по шаблонным функциям можно пошагать отладчиком.
А по сложным выражениям никогда нельзя было пошагать отладчиком иначе, как в режиме дизассемблера. Я бы не отказался от возможности пошагать по отдельным операциям в выражении.
AG>Непонятно, работало бы ли это с гипотетическим макро процессором.
Элементарно. Макропроцессору, встроенному в компилятор, нетрудно оформить порожденный код в отдельный набор строк для отладчика, который кладется в БД с отладочной информацией. Ниоткуда ведь не следует, что отладчик может показывать только то, что лежит в исходных файлах.
Собственно, это можно было бы делать и для существующего препроцессора, но во времена, когда макросы были актуальны, символьных отладчиков, работавших с исходниками, почти не было, а потом макросы объявили вселенским злом, и уже принципиально не стали облегчать работу с ними.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вот будь вместо шаблонов приличный макропроцессор, в котором можно и параметры вызова разобрать, и циклические конструкции использовать, и за счет объединения с компилятором использовать в условиях типы, классы и их свойства — какие у шаблонов остались бы преимущества?
Здравствуйте, Евгений Музыченко, Вы писали: ЕМ>Вот будь вместо шаблонов приличный макропроцессор, в котором можно и параметры вызова разобрать, и циклические конструкции использовать, и за счет объединения с компилятором использовать в условиях типы, классы и их свойства — какие у шаблонов остались бы преимущества?
Ым... Получились бы шаблоны. С каким-то вариациями, конечно, но именно нынешние шаблоны и получились бы.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вот будь вместо шаблонов приличный макропроцессор, в котором можно и параметры вызова разобрать, и циклические конструкции использовать, и за счет объединения с компилятором использовать в условиях типы, классы и их свойства — какие у шаблонов остались бы преимущества?
В свое время одна моя студентка написала вот такой примерно код
#define N 5;
// ...for(int i = 0; i < N *2; i++) {
//
}
Я потратил не помню уж сколько времени, пытаясь понять, что все это значит, и откуда тут indirection, если никаких указателей и близко нет. Пока не догадался посмотреть результат препроцессинга. Посмотреть сам макрос мне в голову не пришло, я и не подумал, что N — это макрос.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Пока не догадался посмотреть результат препроцессинга.
Если бы это был не убогий внешний пре-, а нормальный встроенный макропроцессор, компилятор мог бы выдать вместе с сообщением об ошибке и окрестность конструкции, которая ему не нравится.
Впрочем, содержательность диагностики большинства компиляторов C/C++ — отдельное убожество. Страшно представить, сколько человеко-лет было потрачено впустую из-за этого упертого минимализма.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вот будь вместо шаблонов приличный макропроцессор, в котором можно и параметры вызова разобрать, и циклические конструкции использовать, и за счет объединения с компилятором использовать в условиях типы, классы и их свойства — какие у шаблонов остались бы преимущества?
Темплеты нужно по-любому в достаточно явном виде.
Другой вопрос, что именно их раскрытие — процесс, который сейчас пишется в извращённом виде неявно на языке темплетов, который представляет собой один из худших функциональных языков, которые могут быть, с выражением всех пожеланий в косвенном виде. А мог бы вместо этого иметь явные конструкции для контроля типов, выбора вариантов и прочих необходимых действий...
ЕМ>Если бы это был не убогий внешний пре-, а нормальный встроенный макропроцессор, компилятор мог бы выдать вместе с сообщением об ошибке и окрестность конструкции, которая ему не нравится.
Для этого он должен бы стать компилятором. Только при компиляции выясняется, корректна ли та или иная конструкция или нет. Что, собственно, с шаблонами и имеет место быть.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ> из-за этого упертого минимализма.
Зато Govno Compiler Collection тебе в случае опечатки в параметре шаблонной функции тебе выдаст развёрнутое эссе на тему каждой перегрузки этого шаблона, почему же он не смог тут её применить, и ты будешь не менее минуты листать это эссе, докапываясь до истины. При этом если у тебя где-то случайно делается копирование некопируемого объекта, то в его 1000-страничном эссе не будет ни единого упоминания места, где ты случайно забыл сделать мув или поставить ссылку. А если ты забыл заимплементить метод в реальном наследнике абстрактного класса, то у тебя только линкер скажет, что не найдена ТВМ, и ты наверное даже по этому сообщению сможешь понять, какой именно наследник тебе надо рассмотреть повнимательнее.
Закопайте этот сраный С++ поглубже нафиг, вот что я скажу.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Для этого он должен бы стать компилятором. Только при компиляции выясняется, корректна ли та или иная конструкция или нет. Что, собственно, с шаблонами и имеет место быть.
Почему ты просто не присобачить внешний билд-скрипт, который пишется на том же С++, принимает на вход уже разобранной АСТ-дерево и позволяет посмотреть на результат работы в текстовом виде?
Здравствуйте, T4r4sB, Вы писали:
TB>Зато Govno Compiler Collection тебе в случае опечатки в параметре шаблонной функции тебе выдаст развёрнутое эссе на тему каждой перегрузки этого шаблона, почему же он не смог тут её применить, и ты будешь не менее минуты листать это эссе, докапываясь до истины.
Да и MSVC++ не лучше.
TB>Закопайте этот сраный С++ поглубже нафиг
Весь не надо, а вот иные "продвинутые технологии" лучше бы продвигали поглубже в задницу.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вот будь вместо шаблонов приличный макропроцессор, в котором можно и параметры вызова разобрать, и циклические конструкции использовать, и за счет объединения с компилятором использовать в условиях типы, классы и их свойства — какие у шаблонов остались бы преимущества?
Вам в Rust с его процедурными макросами. И сообщения об ошибках у компилятора Rust восхитительно подробные и ясные.
Здравствуйте, Евгений Музыченко, Вы писали:
С>>Вам в Rust с его процедурными макросами. И сообщения об ошибках у компилятора Rust восхитительно подробные и ясные.
ЕМ>Мне б совместить преимущества того и другого.
Чтобы что-то сделать с C++, нужно очень больше влияние и сообщество. Dlang не взлетел особо, а С++ не поддаётся урезанию. Чтобы воздействовать на комитет С++, нужна большая группа поддержки, поэтому агитацию за макросы надо вести на Реддите, hackernews и проч, а здесь это бессмысленно, по-моему.
Здравствуйте, Слава, Вы писали:
С>агитацию за макросы надо вести на Реддите, hackernews и проч, а здесь это бессмысленно
Да я пока не агитирую. Интересно стало, есть ли у шаблонов в их нынешнем виде какие-либо явные преимущества перед адекватными макросами (о том, что поддерживает C/C++, вообще речи нет).
Теперь мы уже много лет имеем template hell, но настолько привыкли считать, что шаблоны — это круто, что как-то даже стыдно думать об альтернативах. 
