Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вот будь вместо шаблонов приличный макропроцессор, в котором можно и параметры вызова разобрать, и циклические конструкции использовать, и за счет объединения с компилятором использовать в условиях типы, классы и их свойства — какие у шаблонов остались бы преимущества?
Вообще, Музыченко странный тип, он сравнивает то, что есть в плюсах(шаблоны) с какими-то мифическими макросами, которых в С++ нет. И на этом основании делает вывод — шаблоны дерьмо, а вот вымышленные макросы — гуд. При этом, по его же словам, он реально шаблонами не пользовался, представление о них имеет как свинья об апельсине и повторяет мантры всяких неосиляторов про портянки ошибок от которых у них предохранители в голове перегорают и т.д. У меня в проекте практически везде шаблоны и ничего, с приходом концепций все проблемы с неправильными типами параметоров и пр. вообще улетучились. Куча юнит-тестов перенесена в компайл-тайм. Может товарищам с шаблонофобией проверить откуда у них руки растут, может как у осьминогов — из жопы?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Помню, как в начале 90-х все пищали: "ах, шаблоны — это так круто и удобно, попрощаемся же навсегда с macro hell". Теперь мы уже много лет имеем template hell, но настолько привыкли считать, что шаблоны — это круто, что как-то даже стыдно думать об альтернативах. А ведь на обработку сотен-тысяч навороченных макросов требовались ничтожные, по нынешним временам, ресурсы, но сейчас обработка сравнимого количества шаблонов требует многократно бОльших ресурсов, а отлаживать их нередко бывает сложнее, чем макросы.
макросы очень давно существуют в common lisp и работа с ними вполне приятна. На них в частности сделали ООП (aka CLOS) в лиспе.
Если бы для С было схожее + REPL для development режима позволяющий изменять конструкции программы на лету и в частности показывать вид интерпретированных макросов, в С++ возможно не было б нужды
Помнится в колледже я писал библиотеку работы с матрицей, узнал даже про перегрузку операторов, ведь мне нужно было умножение.
Про шаблоны не знал, да вроде и не было ещё тогда их.
Тогда я думал какой взять тип элемента float или double. И сделал typedef.
Потом появилась идея заменить typedef макросом для типа и префикса перед инклюдом библиотеки, чтобы можно было одновременно пользоваться разными матрицами и не писать сто раз одно и тоже. Есть #define, есть #undef — так это можно было сделать. Не очень красиво, зато работает.
Когда я узнал про шаблоны и стал их осваивать сам (на уроке про них тогда не рассказывали), то понял — вот оно. Не надо инклюдить несколько раз один файл, а просто подставить нужный тип элемента и всё.
И не городить огород инклюдов с передифайнами. 1 строчка на дифайн префикса, 1 строчка на дифайн типа, 1 строчка на каждый инклюд. А если надо больше параметров-типов? И не забыть про андифайны после инклюда!
Вы предлагаете вернуться к макросам? Как вы решите такую задачу?
Макросы помогут скажем сделать умножение двух матриц с разными типами элемента? Если да, то покажите как.
Да хоть на любой другой задаче...
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Помню, как в начале 90-х все пищали: "ах, шаблоны — это так круто и удобно, ЕМ>...
Шёл 2022 год. Народ уже давно освоил лямбды, constexpr и вариадические шаблоны, и также вовсю начал юзать async, концепты и модули... Тем временем Евгений Музыченко занялся вопросом чем шаблоны лучше макросов
начинаю подозревать что кроме того что вы тролль
вы уже и не имеете никакого отношение к современному программированию
ну кроме тех программ которые вы написали в году так 1998, и с болью пытаетесь компилировать современным компилятором
#define MAX(x,y) (x)>(y)?(x):(y)
int val = 1;
int get_val()
{
return val++;
}
int main()
{
#ifdef MAX
printf("max %d\n",MAX(get_val(),get_val()));
#else
printf("max %d\n",std::max(get_val(),get_val()));
#endif
}
Здравствуйте, Sm0ke, Вы писали:
S>И не городить огород инклюдов с передифайнами. 1 строчка на дифайн префикса, 1 строчка на дифайн типа, 1 строчка на каждый инклюд. А если надо больше параметров-типов? И не забыть про андифайны после инклюда!
Все описанное в основном является следствием не макросов, как таковых, а отделения препроцессора от компилятора, и крайним убожеством первого.
S>Вы предлагаете вернуться к макросам?
Я предлагаю сравнить функциональнось и удобство современных шаблонов с адекватно реализованными макросами. Если Вы никогда не видели макросов, отличных от сишных, то Вам нет смысла и сравнивать.
Здравствуйте, A13x, Вы писали:
A>Если бы для С было схожее + REPL для development режима позволяющий изменять конструкции программы на лету и в частности показывать вид интерпретированных макросов, в С++ возможно не было б нужды
Внезапно, вижуалка показывает, во что раскрывается макрос, если на него навести мышку
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Элементарно. Макропроцессору, встроенному в компилятор, нетрудно оформить порожденный код в отдельный набор строк для отладчика, который кладется в БД с отладочной информацией. Ниоткуда ведь не следует, что отладчик может показывать только то, что лежит в исходных файлах.
Наверное, надо менять формат отладочной БД, и от этого куча всего поломается
Здравствуйте, удусекшл, Вы писали:
У>Внезапно, вижуалка показывает, во что раскрывается макрос, если на него навести мышку
Только если IntelliSense сработало правильно. Если обломалось (например, фатальная ошибка при компиляции), то не покажет. Придется привести текст к виду, в котором он хоть как-то компилируется, и при этом структура макроса не изменится.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я предлагаю сравнить функциональнось и удобство современных шаблонов с адекватно реализованными макросами. Если Вы никогда не видели макросов, отличных от сишных, то Вам нет смысла и сравнивать.
Конкретные примеры можно? Я же не буду искать все реализации макросов вообще во всех языках ...
Здравствуйте, Sm0ke, Вы писали:
ЕМ>>Я предлагаю сравнить функциональнось и удобство современных шаблонов с адекватно реализованными макросами. Если Вы никогда не видели макросов, отличных от сишных, то Вам нет смысла и сравнивать.
S>Конкретные примеры можно? Я же не буду искать все реализации макросов вообще во всех языках ...
Я так понимаю, что он хочет что-то типа доступа к AST, чтобы можно было писать простые функции с циклами, набивающие AST дополнительными штуками, и чтобы эти функции писались на том же C++ и исполнялись во время компиляции. Что-то такое есть в C# вроде.
Но вообще — это может быть годно только как дополнение к текущему языку и его шаблонам. Потому что если резать шаблонную магию, то придётся таких генераторов для набивки AST пачками писать. Ну а Евгений не очень в шаблоны умеет, поэтому и хочет такой велосипед с квадратными колёсами
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Помню, как в начале 90-х все пищали: "ах, шаблоны — это так круто и удобно, попрощаемся же навсегда с macro hell". Теперь мы уже много лет имеем template hell, но настолько привыкли считать, что шаблоны — это круто, что как-то даже стыдно думать об альтернативах. А ведь на обработку сотен-тысяч навороченных макросов требовались ничтожные, по нынешним временам, ресурсы, но сейчас обработка сравнимого количества шаблонов требует многократно бОльших ресурсов, а отлаживать их нередко бывает сложнее, чем макросы.
ЕМ>При этом, изрядная доля macro hell происходила лишь от того, что обработка исходника была искусственно разделена на препроцессирование и компиляцию. В начале 70-х это еще можно было как-то оправдать нехваткой ресурсов, хотя убогие возможности сишного препроцессора вряд ли могли заметно утяжелить компилятор. Имей компилятор возможность хотя бы просто выдать в сообщении об ошибке как исходную конструкцию, так и результат ее обработки макропроцессором, это свело бы на нет бОльшую часть проблем.
ЕМ>Современные компиляторы используют предкомпиляцию шаблонов, но она, по сути, не столько ускоряет компиляцию вообще, сколько снижает тормоза, создаваемые множеством многоуровневых шаблонных конструкций. И все равно оптимизатору приходится как-то систематизировать функции, чтобы объединить те, что отличаются только типами, но при этом не оформлены ни в шаблоны, ни в перегрузки.
Так исторически сложилось, что препроцессор, унаследованный от C, во первых слишком убог, во вторых, воспринимает код как текст и ничего не знает о классах и функциях. Но из-за обратной совместимости, с ним ничего не сделаешь. Мысль о том, что макросы должны быть более умными и понимать семантику языка уже давным давно приходила в голову многим, но никто толком не знал, как же это должно выглядеть.
Шаблоны изначально создавались, как простой механизм для параметризации типов. То, что с их помошью можно делать всякую магию и организовать условную компиляцию и кодогенерацию получилось совершенно случайно и для многих было неожиданным. Так получилось, что в языке уже оказалось средство, которое могло решить многие проблемы убогого препроцессора. Синтаксис шаблонов был ужасен, так как их делали для других целей, но проблема решалась сама собой, не нужно было придумывать новый метаязык и долго решать проблемы обратной совместимости. Предполагалось, что синтаксис шаблонов можно будет потихоньку доработать до чего-то более менее удобного. Но и тут оказалось все совсем не просто, не получилось и сохранить обратную совместимость и упростить синтаксис, в итоге получилось что синтаксис только усложнялся и продолжает усложняться.
ЕМ>Считается, что функциональный стиль использования шаблонов — это благо, но многие ли способны быстро разобраться в иерархии и взаимодействии шаблонов в какой-нибудь Boost? В конце концов, какая часть математиков интуитивно воспринимает факториал, как отображение множества целых чисел само на себя, или, на худой конец, как рекурсию, а не как последовательное (итеративное) произведение?
ИМХО никто так не считает, просто так получилось, а что-то серьезное менять боятся.
ЕМ>Вот будь вместо шаблонов приличный макропроцессор, в котором можно и параметры вызова разобрать, и циклические конструкции использовать, и за счет объединения с компилятором использовать в условиях типы, классы и их свойства — какие у шаблонов остались бы преимущества?
Ну, вот "if constexpr", который позволяет нормально выбрать условие во время компиляции вместо жутких enable_if и SFINAE в язык все таки добавили, хотя и осилили только к 17 стандарту.
Разговоры про compile_time reflection идут давным давно, но не похоже что это скоро попадет в язык.
Вон Саттер еще давно делал доклад о всяких метаклассах: www.youtube.com/watch?v=4AfRAVcThyA
Но никто не готов на такие радикальные перемены, потому, что нет уверенности что мы не сделаем синтаксис еще более непонятным и запутанным.
Здравствуйте, удусекшл, Вы писали:
У>Я так понимаю, что он хочет что-то типа доступа к AST, чтобы можно было писать простые функции с циклами, набивающие AST дополнительными штуками, и чтобы эти функции писались на том же C++ и исполнялись во время компиляции.
Не, это было бы неоправданно сложным в реализации. А вот если бы при раскрытии макроса можно было проанализировать его параметры (типы, имена объектов, функций, константы и т.п.), и породить код, зависящий от ряда условий, то большинство конструкций, традиционно реализуемых на шаблонах, выглядело бы куда приятнее/понятнее, и было бы проще в отладке.
У>Потому что если резать шаблонную магию
Будь у языка изначально приличный макропроцессор, шаблонная магия не имела бы шансов возникнуть. Она ж возникла, по сути, от безысходности, это уже потом фанаты вроде Александреску убедили всех, что не умеющий чесать левое ухо правой ногой заслуживает порицания, если не презрения.
У>а Евгений не очень в шаблоны умеет
Евгений в шаблоны умеет, если очень надо. Но многоэтажные рекурсивные конструкции, работающие, по сути, на побочных эффектах, ему глубоко антипатичны.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А вот если бы при раскрытии макроса можно было проанализировать его параметры (типы, имена объектов, функций, константы и т.п.), и породить код, зависящий от ряда условий, то большинство конструкций, традиционно реализуемых на шаблонах, выглядело бы куда приятнее/понятнее, и было бы проще в отладке.
Здравствуйте, Евгений Музыченко, Вы писали:
У>>Я так понимаю, что он хочет что-то типа доступа к AST, чтобы можно было писать простые функции с циклами, набивающие AST дополнительными штуками, и чтобы эти функции писались на том же C++ и исполнялись во время компиляции.
ЕМ>Не, это было бы неоправданно сложным в реализации. А вот если бы при раскрытии макроса можно было проанализировать его параметры (типы, имена объектов, функций, константы и т.п.), и породить код, зависящий от ряда условий, то большинство конструкций, традиционно реализуемых на шаблонах, выглядело бы куда приятнее/понятнее, и было бы проще в отладке.
Ну, то есть те же самые C++ шаблоны, + концепты из нового стандарта
У>>Потому что если резать шаблонную магию
ЕМ>Будь у языка изначально приличный макропроцессор, шаблонная магия не имела бы шансов возникнуть. Она ж возникла, по сути, от безысходности, это уже потом фанаты вроде Александреску убедили всех, что не умеющий чесать левое ухо правой ногой заслуживает порицания, если не презрения.
Ну, то есть, ты хотел бы, чтобы шаблоны с концептами были сразу в CFront? Ну, такое маловероятно. Думаю, никто тогда такого вообще и помыслить не мог. Побочные явления, типа SFINAE, которое использовал Александреску, были в общем-то случайно обнаружены.
Не что-то могу припомнить, в каком бы языке такое было бы сразу искаропки. Ну, может, Rust какой-нибудь. Ну, тут надо просто посмотреть на даты создания языков... И тот же раст писали люди знакомые с современными (хотя бы на тот момент) плюсами
У>>а Евгений не очень в шаблоны умеет
ЕМ>Евгений в шаблоны умеет, если очень надо. Но многоэтажные рекурсивные конструкции, работающие, по сути, на побочных эффектах, ему глубоко антипатичны.
Здравствуйте, ksandro, Вы писали:
K>из-за обратной совместимости, с ним ничего не сделаешь.
С чего бы вдруг? Есть множество способов расширения и синтаксиса, и семантики без малейшей потери совместимости.
K>Мысль о том, что макросы должны быть более умными и понимать семантику языка уже давным давно приходила в голову многим, но никто толком не знал, как же это должно выглядеть.
Так хоть бы попытались несколько раз. А то такое впечатление, что хаотично мечутся, добавляя сугубо частные возможности и закрывая столь же частные бреши, а об универсальных возможностях думают меньше всего.
K>Шаблоны изначально создавались, как простой механизм для параметризации типов. То, что с их помошью можно делать всякую магию и организовать условную компиляцию и кодогенерацию получилось совершенно случайно и для многих было неожиданным.
Это я в курсе. Но еще более неожиданным стало стремление делать на шаблонах все, что было технически возможным. А в силу пресловутой полноты оказалось, что делать на них можно вообще все без исключения. И возобладал подход "на кой совершенствовать язык, если можно нагородить пару десятков или сотен тысяч строк на шаблонах? нужно совершенствовать шаблоны!".
K>Предполагалось, что синтаксис шаблонов можно будет потихоньку доработать до чего-то более менее удобного. Но и тут оказалось все совсем не просто
Если изо всех сил держаться за функциональный подход — непросто. А если принять возможность процедурного подхода, то в любой момент можно добавить конструкций для анализа и перебора параметров, условного включения фрагментов кода, повторения похожих по виду конструкций и т.п. Такая проблема давно известна — например, даже простейшие алгоритмы, будучи реализованы в виде конечных автоматов, могут приобретать совершенно неприличный вид и изрядную сложность в отладке.
ЕМ>>Считается, что функциональный стиль использования шаблонов — это благо
K>ИМХО никто так не считает, просто так получилось
Да ну, полно приверженцев ФП, для которых любая новая функциональная конструкция — еще один шаг к божественному.
K>Ну, вот "if constexpr"
Да, хороший пример сугубо частного решения. А при грамотном подходе еще полвека назад #ifdef мог бы работать так же.
Здравствуйте, ArtDenis, Вы писали:
AD>Можно пример как это может выглядеть?
Ну вот шаблоны type traits реализованы так, что для определенных типов они явно специализированы с нужными значениями констант, а для остальных выбираются варианты по умолчанию. То есть, это устроено задом наперед, при этом установка и извлечение значений констант работает, по сути, на побочных явлениях. Если бы в языке был способ "интеллектуального" раскрытия хоть макросов, хоть шаблонов, то можно было бы проверять заданный параметром тип обычными условными конструкциями вроде #ifdef.
А если бы в языке изначально были условные конструкции, работающие на уровне компилятора (вроде __if_exists в MSVC), то из этого естественным образом вытекало бы и наличие встроенных предикатов для типов, переменных, функций, шаблонов и прочего. Вот тогда было бы одновременно и удобно, и красиво, и в реализации недорого.
Теперь мы уже много лет имеем template hell, но настолько привыкли считать, что шаблоны — это круто, что как-то даже стыдно думать об альтернативах. 
