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

ЕМ>>Он был очень примитивен по сравнению с "серьезными" ЯВУ того времени.

S>Это с какими, например? COBOL и PL/I?

Вы издеваетесь? Эти появились еще до того, как C более-менее оформился и пошел в массы. Также до C были LISP, SNOBOL, ALGOL-68, Simula-67, REFAL, SETL — это только из наиболее популярных. Между C и C++ были (опять-таки из наиболее известных) Prolog, Simula-74, Smalltalk, Modula.

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

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

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

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

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

При том, что Simula сама по себе прекрасно справлялась [почти] с любыми высокоуровневыми задачами, для которых предназначался C++. Не будь цели сделать универсальный язык, можно было бы продолжать обходиться C для простых/низкоуровневых задач, и "серьезными" ЯВУ, включая Simula, для остальных.

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

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

Да пожалуйста.

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

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

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

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

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

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

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

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

S>Шаблоны позвляют делать очень многое.

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

S>Поэтому они очень гибкие. Обратной стороной является их сложность.

Если перед "гибкие" добавить "относительно", а перед "сложность" — "многократно преувеличенная", то соглашусь.

S>Но если вы 40 лет программируете на Си с классами, а в шаблоны не умеете

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

S>Т.е. Пастернака не читал, но осуждаю.

Почему не читал? Как раз читал. Видел, что в ряде случаев это может быть полезно, но у меня пока не было насущной потребности это применять. И, кстати, адекватный макропроцессор, будь он в языке вместо шаблонов, позволил бы относительно просто реализовать такое в виде надстройки — то есть, будучи сделано кем-то для себя, оно автоматически стало бы доступно всем пользователям языка. А так оно появляется в реализациях только по мере поддержки очередных стандартов разработчиками компиляторов.

S>Даже до того, что есть со structured binding пришлось идти очень долго.

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

S>в области ООП C++ тогда был один из первопроходцев среди мейнстримных языков.

К этой части претензий как раз [почти] нет.

S>Пример кода можете показать?

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