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

A>Ты не поверишь...
A>https://rsdn.org/article/mag/200401/codestyle.XML#EIIAE

Охотно верю — это и есть соглашение внутри локальной группы. Те, кто в ней не участвует (например, я), не обязаны ничего об этом знать.

A>Простой пример. Я когда-то спрашивал

Автор: Alekzander
Дата: 17.06.23

, как написать в плюсах is in set.

Тут нужно начать с того, что задача именно в таком виде не является достаточно типовой, чтобы иметь в языке какие-то свойства именно под нее. А вот возможность определять наборы идентификаторов, по аналогии с перечислимым типом в Pascal, и делать из них множество, была бы весьма полезна. Тем более, что этот механизм естественным образом ложится на битовые операции (операции с множествами в Pascal компилируются в банальные or, and, test).

A>В Си это делается при помощи пачки макросов IS_IN_SET2(), IS_IN_SET3() ... IS_IN_SETN(), связанных вариадическим макросом. Это ужасное решение, безусловно.

Полностью согласен.

A>Но это РЕШЕНИЕ. А вот если сравнить его с самым лучшим предложенным плюсовым кодом (конечно же, на шаблонах), то. Начнём с того, что оно тоже очень корявое.

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

A>Есть такое соглашение (среди создателей языков), что шаблоны это обобщения на типы, а не просто черезжопный интерфейс к препроцессору.

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

A>Но плюсовики, как ты выше, делают удивлённые глаза: мы про такие соглашения ничего не слышали!

Вы меня точно ни с кем не путаете? Или каждого, кто выступает в поддержку C++ в любой его форме, автоматически записываете в ревнители "канонических плюсов", которые нынче преобладают?

A>Очевидное условие — отсутствие паразитного call'а, потому что если ты на него согласен, хватит и простой перегрузки функций.

inline не спасает?

A>Альтернативой был бы нормальный препроцессор, а не говно мамонта из языка Си.

Адекватной альтернативой был бы не препроцессор, с его сугубо текстовыми параметрами/подстановками, а нормальные средства условной компиляции. Чтоб шаблон мог узнать у компилятора любые подробности любого из своих параметров, включить в порождаемый код любой из своих элементов в зависимости от условия, если параметров переменное количество — наглядно перебрать их в конструкции вроде "псевдоцикла", работающего во время компиляции, на любом этапе вывести сообщение, и т.п. Примерно так работают классические макропроцессоры.

A>Выше уже написали: попробуйте, если такие смелые. Посмотрим, сколько на нём программистов останется.

Ну вот Вы бы ушли с удобного в целом языка лишь потому, что его компилятор по умолчанию стал выдавать множество предупреждений (которые, если их внимательно прочитать, чаще всего спасают Вас от вероятных косяков, нежели просто надоедают из вредности), любое из которых, или даже все вместе, можно подавить пометками в тексте программы или ключами компилятора?

A>И так все поразбежались

Поразбежались в основном те, кто предпочитал использовать разумное подмножество C++ (как я, например), но руководство заставляет их переходить на "современный стиль", вызывающий рвотный рефлекс. Если человеку нужно просто решать задачи, и ему не диктуют в деталях правил их решения, что может согнать его с инструмента?

A>Нахера мне нужен язык с ручным управлением памятью, если в нём кастинг и инициализация работают не как в Си?

Вот сейчас вообще не понял. Какая между этим связь? Это ж совершенно ортогональные друг другу вещи.

A>Создатели плюсов поступили очень умно, решив, вот именно, ПАРАЗИТИРОВАТЬ на Си. Если бы они сделали всё то, что ты предлагаешь, у них бы получилось что-то типа D. То есть, дико популярное, но только в очень узких кругах.

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

Если так, то что они делают на C? Почему они не пишут на ассемблерах, или даже в машинном коде? Ведь и в C, и даже в ассемблерах, непременно есть какой-то контроль, который никак не обойти.