Здравствуйте, удусекшл, Вы писали:
У>Ну, то есть те же самые C++ шаблоны, + концепты из нового стандарта
Концепты — очередной сугубо частный костыль, чтоб, упаси боже, не нарушить священную функциональную парадигму.
У>ты хотел бы, чтобы шаблоны с концептами были сразу в CFront?
Я хотел бы, чтоб концептов не было вообще, а конструкции вроде шаблонов были еще в позднем C — хоть на основе макросов (но не традиционных, а более адекватных).
У>Думаю, никто тогда такого вообще и помыслить не мог.
Да ну, макросредства в языках появились достаточно давно, но более убогих, чем в C/C++, насколько я знаю, нигде не было и нет. А делается-то ведь примитивно до невозможности. У компилятора всегда есть вся необходимая информация о программных элементах. Добавляем простые конструкции для извлечения этой информации, и столь же простые конструкции для условной компиляции по их результатам. Все, на этом просто и изящно делается львиная доля того, что было наколхожено на шаблонах за все время их существования.
У>Побочные явления, типа SFINAE, которое использовал Александреску, были в общем-то случайно обнаружены.
Да. И само то, что их так охотно подхватили и стали продвигать, лучше всего иллюстрирует извращенный характер мышления этих людей. Это что-то вроде строительства дома из пластиковых бутылок — выглядит круто и необычно, позволяет обрести известность и прослыть гуру, но для массового применения никак не годится.
У>Не что-то могу припомнить, в каком бы языке такое было бы сразу искаропки.
Например, в ассемблере 360/370 (60-е годы) был неимоверно мощный и удобный макропроцессор, на нем можно было черта сделать, поскольку там была доступна информация о трансляции (адреса, размеры переменных и т.п.). Но вот в ЯВУ почему-то всегда так получалось, что есть либо чистый макропроцессор (на уровне абстрактных лексем), либо навороченный (и часто полуинтерпретируемый) язык, либо скудный язык и минимумом или полным отсутствием макросредств.
Здравствуйте, TailWind, Вы писали:
TW>В 99% случаев хватает виртуальных функций
Если не требуется виртуальности во время выполнения, то некоторые вещи и удобно, и экономно реализуются на шаблонах. Но с ростом сложности очень быстро растет извращенность конструкций и количество требуемых костылей. Тут главное — вовремя остановиться.
TW>- сложность понять что написал 5 лет назад на шаблонах (имел негативный опыт)
Я с некоторых пор взял за правило описывать причины выбора тех или иных подходов, решений, конструкций — или в комментариях, или отдельно. Любая мало-мальски нетипичная конструкция через несколько лет рискует показаться бессмысленной и ненужной, а при удалении/переделке лезут глюки, и тогда вспоминается, для чего было сделано именно так.
Re[11]: Чем современные шаблоны лучше макросов? :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вот будь вместо шаблонов приличный макропроцессор, в котором можно и параметры вызова разобрать, и циклические конструкции использовать, и за счет объединения с компилятором использовать в условиях типы, классы и их свойства — какие у шаблонов остались бы преимущества?
Как вы на макропроцессоре решите следующую задачу:?
#include <iostream>
class Out
{
public:
Out& operator << (int n);
Out& operator << (const char* pStr);
template <class T>
Out& operator << (T) = delete;
};
Out& Out::operator << (int n)
{
std::cout << n;
return *this;
}
Out& Out::operator << (const char* pStr)
{
std::cout << pStr;
return *this;
}
int main()
{
Out o;
int x = 1;
o << x << "\n";
unsigned int u = 0xFFFFFFFF;
o << u << "\n";
o << "\n the end \n";
return 0;
}
У>Я так понимаю, что он хочет что-то типа доступа к AST, чтобы можно было писать простые функции с циклами, набивающие AST дополнительными штуками, и чтобы эти функции писались на том же C++ и исполнялись во время компиляции. Что-то такое есть в C# вроде.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>С чего бы вдруг? Есть множество способов расширения и синтаксиса, и семантики без малейшей потери совместимости.
С того, что тут придется создавать еще один метаязык, который должен как-то не испортить текущие шаблоны и макросы, мне кажется никто не готов взять на себя такую огромную работу. С++ и так уже переусложнен. Проблема в том, что это надо еще согласовать в коммитете по стандартизации. Никто за это не возьмется.
ЕМ>Так хоть бы попытались несколько раз. А то такое впечатление, что хаотично мечутся, добавляя сугубо частные возможности и закрывая столь же частные бреши, а об универсальных возможностях думают меньше всего.
Так пытаются, есть всякие предложения по reflection и обсуждают идеи метаклассов, но когда от абстрактных идей переходят к более менее конкретной логике, то понимают, что не осилят...
ЕМ>Это я в курсе. Но еще более неожиданным стало стремление делать на шаблонах все, что было технически возможным. А в силу пресловутой полноты оказалось, что делать на них можно вообще все без исключения. И возобладал подход "на кой совершенствовать язык, если можно нагородить пару десятков или сотен тысяч строк на шаблонах? нужно совершенствовать шаблоны!".
Тут соглашусь, то, что с помощью шаблонов можно уже сейчас делать всякие прикольные штуки уже сейчас, а не ждать нового стандарта больше 10 лет, было для многих откровением. Поэтому на шаблонах все и стали делать.
Потом народ начал осознавать, что как-то слишком все переусложняется, но нормального другого решения пока так никто и не предложил. Нет никакой гарантии, что новый метаязык, который может быть когда-нибудь заменит шаблоны будет проще.
ЕМ>Если изо всех сил держаться за функциональный подход — непросто. А если принять возможность процедурного подхода, то в любой момент можно добавить конструкций для анализа и перебора параметров, условного включения фрагментов кода, повторения похожих по виду конструкций и т.п. Такая проблема давно известна — например, даже простейшие алгоритмы, будучи реализованы в виде конечных автоматов, могут приобретать совершенно неприличный вид и изрядную сложность в отладке.
Только вот примеров такого успешного внедрения мейнстрим в языки подобных фич, как-то не видно. Говорят в Расте что-то похожее есть, надо будет как-нибудь глянуть как будет время. А больше вроде нигде, все только в runtime.
Дело не в функциональном стиле, дело в том, что никому не хотелось добавлять еще один метаязык к существующим уже шаблонам и препроцессору.
ЕМ>Да ну, полно приверженцев ФП, для которых любая новая функциональная конструкция — еще один шаг к божественному.
У ФП, есть много преимуществ, например лучшее распараллеливание, лучшие возможности для ленивых вычислений и др. Но какие же реальные плюсы преимущества есть от ФП в шаблонном метапрограммировании. Просто других вариантов для С++ нет. И никто не осиливает сделать. Поэтому пользуются тем, что есть.
ЕМ>Да, хороший пример сугубо частного решения.
Ну, не все сразу. Вот когда-нибудь придумают синтаксис для compile-time списка разнотипных аргументов, и добавят "constexpr for", и будет счастье!
ЕМ>А при грамотном подходе еще полвека назад #ifdef мог бы работать так же.
Мне кажется тогда никто серьезно не задумывался о метапрограммировании... Считали что препроцессора достаточно.
Re[14]: Чем современные шаблоны лучше макросов? :)
Здравствуйте, Евгений Музыченко, Вы писали:
BFE>>Как вы на макропроцессоре решите следующую задачу:? ЕМ>В чем именно заключается задача?
Запретить неявное преобразование типа.
ЕМ>И объем этого кода точно меньше, чем ее словесное описание?
Слова не точны, а код... Этот код хорош тем, что он не компилируется.
Здравствуйте, Евгений Музыченко.
Макросы, объединенные с компилятором, это уже не просто макросы, а полноценные языковые конструкции. В которых, наверняка, будут и перегрузки, и рекурсия, и вариадики и прочие навороты. И все эти навороты нужно будет как-то записывать и поддерживать. Поэтому, противопоставляя одно другому, вы должны точно очертить, в чем принципиально "хорошие" макросы будут отличаться от текущих шаблонов. Простота и мощь текущих макросов, конечно, заманчива и кажется, что их "чуть чуть развить" и сразу они "похоронят" "переусложнённые" шаблоны. Но это только так кажется.
Здравствуйте, ksandro, Вы писали:
K>С того, что тут придется создавать еще один метаязык, который должен как-то не испортить текущие шаблоны и макросы, мне кажется никто не готов взять на себя такую огромную работу.
Я ж не говорю, что это нужно делать сейчас — поздно, поезд давно уже идет под откос. А вот лет 20-30 назад, когда уже было достаточно хорошо видно, что template hell будет покруче macro hell, впору было задуматься.
K>Так пытаются, есть всякие предложения по reflection и обсуждают идеи метаклассов, но когда от абстрактных идей переходят к более менее конкретной логике, то понимают, что не осилят...
Во многом — потому, что пытаются удержаться в рамках принятой парадигмы. А в этом нет смысла — язык давно потерял всякое подобие стройности и логичности, и уже почти нет разницы, с какой стороны и в каком виде громоздить новое.
K>то, что с помощью шаблонов можно уже сейчас делать всякие прикольные штуки уже сейчас, а не ждать нового стандарта больше 10 лет, было для многих откровением. Поэтому на шаблонах все и стали делать.
И стало это сильно напоминать известный анекдот.
K>Вот когда-нибудь придумают синтаксис для compile-time списка разнотипных аргументов, и добавят "constexpr for", и будет счастье!
Да, с новым костылем, столь же частным, сколь и остальные.
ЕМ>>еще полвека назад #ifdef мог бы работать так же.
K>Мне кажется тогда никто серьезно не задумывался о метапрограммировании...
О метапрограммировании и задумывались, и пробовали еще раньше.
K>Считали что препроцессора достаточно.
Подозреваю, что в основном люди просто не видели нормальный реализаций макропроцессора.
Re[15]: Чем современные шаблоны лучше макросов? :)
Здравствуйте, Went, Вы писали:
W>Макросы, объединенные с компилятором, это уже не просто макросы, а полноценные языковые конструкции.
Ну да. Это средства, позволяющие компилятору при обработке исходного кода порождать новый исходный код, и тут же его обрабатывать.
W>В которых, наверняка, будут и перегрузки, и рекурсия, и вариадики и прочие навороты.
Зачем там перегрузки? Каково их возможное применение? Рекурсия там была бы обязательно, но контролируемая более явно и точно, нежели в шаблонах. "Вариадики" в таких конструкциях не нужны — это костыль исключительно для функционального стиля. Представьте, что в сишную main вместо argc/argv передавались бы "вариадики".
W>вы должны точно очертить, в чем принципиально "хорошие" макросы будут отличаться от текущих шаблонов.
Я ж вроде описал — более естественным и понятным способом развертывания, обработки параметров, управления порождением кода. Тем же, чем любой процедурный язык отличается от любого функционального. Математические задачи, моделирование и подобное на ФЯ решаются удобно и изящно, но как доходит до реализации обычного последовательного алгоритма, так сразу начинаются пляски.
W>Простота и мощь текущих макросов
У Вас слишком много ошибок в словах "примитивность" и "убожество".
W>кажется, что их "чуть чуть развить" и сразу они "похоронят" "переусложнённые" шаблоны.
Повторю: речь не о том, чтобы сейчас заменить шаблоны "продвинутыми макросами" — это очевидно невозможно без создания новой версии языка. Речь о том, что сперва был реализован примитивный и неудобный препроцессор, затем он заботливо сохранялся два десятка лет, а затем, "для избавления от macro hell", были созданы шаблоны, которые создали hell почище прежнего.
Re[17]: Чем современные шаблоны лучше макросов? :)
