Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Вы издеваетесь?

Нет.

ЕМ>ALGOL-68 и Modula.

И чем же они ЯВУ, а Си -- нет?

Включение же в список кучи языков с GC для сравнения их с чистым Си -- это от большого ума?
Как и попытка сопоставить Си и Prolog (популярность которого, даже в конце 1980-х и начале 1990-х сильно преувеличена).

S>>Вы с чем спорите?

ЕМ>С тем, что Вам, насколько я знаю из того, что Вы пишете про C++, неинтересны низкоуровневые и архитектурно-зависимые возможности C++, унаследованные от C.

Значит вы ничего не знаете.

S>>"Цель создания C++ была в том, чтобы скрестить Симулу с Си. Что выразилось в добавлении в Си классов и наследования."

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

Так по факту же именно это и получилось.

S>>При чем здесь "у языка Simula было такое название"?

ЕМ>При том, что Simula сама по себе прекрасно справлялась

Да, да, да. Страуструпа, вы, видимо, не читали от слова совсем:

Однако реализация самого языка Simula не масштабировалась в той же степени, что и моя программа. В результате весь проект чуть не закончился крахом. В то время я пришел к выводу, что реализация Simula (в отличие от самого языка) была ориентирована на небольшие по объему программы, а для больших не приспособлена. На связывание отдельно скомпилированных классов уходила масса времени: на компиляцию 1/30 части программы и связывание ее с остальными, уже откомпилированными модулями тратилось больше времени, чем на компииляцию и связывание всей программы как монолита. Думаю, что, вероятнее всего, это была проблема используемого компоновщика, а не самого языка Simula, но это слабое утешение. Кроме того, производительность программы была такой низкой, что не оставляла надежд получить от симулятора хоть сколько-нибудь полезные данные. Плохие показатели производительности были обусловлены языком и его реализацией, а не приложением. Проблема накладных расходов является в Simula фундаментальной и неустранимой. Она коренится в некоторых особенностях языка и их взаимодействиях: проверке типов во время исполнения, гарантированной инициализации переменных, поддержке параллельности, сборке мусора для объектов, созданных пользователем, и записей активации процедур.

Так что ваше мнение о "прекрасно справлялась" и мнение Страуструпа здесь драматически расходятся.

ЕМ>>>Возможных для заимствования первоисточников были десятки.

S>>Список в студию, пожалуйста.

ЕМ>Да пожалуйста.

Это называется "на деревню дедушке".

S>>Покажите другие подходы.

ЕМ>Я уже неоднократно показывал — почти любой мало-мальски продвинутый макрогенератор. Где макрос — это не просто кусок текста, в который можно подставить параметры, а процедура/функция (обычно на особом макроязыке), выполняемая на этапе компиляции. Которая может разобрать список своих параметров, сопоставить их с известными компилятору объектами (типами, переменными, функциями и т.п.)

А мы сейчас точно о макросах говорим? Макросы же обрабатываются до начала работы компилятора и формируют код, который уже идет на вход компилятору. Т.е. для макроса еще нет "известных компилятору объектов".

Кроме того, именно то, что вы описываете, как раз C++ными шаблонами и делается: разбор параметров, сопоставление и т.д.

И позвольте спросить, а как в этом вашем идеальном макрогенераторе решать ту проблему, для которой в C++ добавили специализацию шаблонов (хоть полную, хоть частичную)?

ЕМ>породить текст для последующей компиляции, подставив туда хоть параметры (как в исходном, так и в преобразованном виде), хоть произвольно сгенерированные строки

А это уже завозят в рамках C++26. Не без помощи шаблонов.

ЕМ>при необходимости сопровождая свою работу сообщениями в общий поток вывода компилятора.

Этого пока нет.

ЕМ>Да, это гораздо сложнее тупых сишных макросов, и даже немного сложнее первой инкарнации плюсовых шаблонов

Мне кажется, что вы и про первую инкарнацию шаблонов знаете почти ничего.

S>>Связь не у шаблонов, а у возможностей и ограничений языков с GC и без.
S>>C++ находится в категории языков без GC, поэтому сравнивать его с условными Haskell/OCaml/Scala ну такое себе.

ЕМ>Вот вообще не вижу ни малейшей связи.

Очередной пустопорожний бла-бла-бла поскипан.

S>>родите, например, список языков, в которых шаблоны гибче, чем в C++?

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

Т.е. заявления есть, подтверждений нет. Ожидаемо.

ЕМ>А смысл? Если Вам понятна сама идея, то что может дать код сверх нее? Если же идея со слов непонятна, то как Вы собираетесь понимать код?

А вы рискните. Пока что вы в очередной раз выступили в духе "за все хорошее против всего плохого". И с конкретикой у вас, по традиции, очень плохо. Очень.