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

A>>Есть старое соглашение: если две строки кода написаны подряд, а комментарий — через вертикальный пробел, он относится ко всему блоку.

ЕМ>Если такое соглашение и есть, это лишь одно из множества разных соглашений, которые по факту являются соглашениями в относительно локальных группах. Ну и вряд ли стоит распространять стили кодирования формальных языков на естественные. Так недалеко до КГ/АМ, КД-ЧД и подобного.

Ты не поверишь...

https://rsdn.org/article/mag/200401/codestyle.XML#EIIAE

Соглашения по оформлению кода команды RSDN
...
Между группой комментариев и собственно кодом поставьте пустую строку. Это покажет, что комментарий относится к блоку кода, а не к конкретной инструкции. Напротив, если комментарий относится к конкретной инструкции, прижмите его вплотную к этой инструкции.

A>>Комментарий "+100500" относился ко всему блоку, а в первую очередь к "C++ на этой совместимости до сих пор паразитирует". Я видел крайне мало проектов, написанных на C++. Большинство написано на квазиязыке под названием "C/C++". И если бы от людей требовалось выбрать, C++ без C или C без C++, я бы на C++ не поставил.

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

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

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

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

В Си это делается при помощи пачки макросов IS_IN_SET2(), IS_IN_SET3() ... IS_IN_SETN(), связанных вариадическим макросом. Это ужасное решение, безусловно. Если написать такой код: https://stackoverflow.com/a/11763277/14400772, можно нечаянно вызвать Сатану. А если ещё заставить его работать в студийном компиляторе: https://stackoverflow.com/a/5134656/14400772, то можно разбудить Ктулху.

Но это РЕШЕНИЕ. А вот если сравнить его с самым лучшим предложенным плюсовым кодом (конечно же, на шаблонах), то. Начнём с того, что оно тоже очень корявое. Есть такое соглашение (среди создателей языков), что шаблоны это обобщения на типы, а не просто черезжопный интерфейс к препроцессору. Но плюсовики, как ты выше, делают удивлённые глаза: мы про такие соглашения ничего не слышали! Пусть это будет на их совести, но факт в том, что это, строго говоря, НЕ РЕШЕНИЕ. Очевидное условие — отсутствие паразитного call'а, потому что если ты на него согласен, хватит и простой перегрузки функций.

Мало того, что #define это по духу чисто сишный подход, так необходимая часть (__VA_ARGS__) ещё и не поддерживалась в плюсах аж 12 лет. При отсутствии альтернативы. Альтернативой был бы нормальный препроцессор, а не говно мамонта из языка Си. Вот поэтому и приходится смешивать старые и новые напластования: вариантов просто нет. Что, конечно, само по себе не очень хорошо.

ЕМ>Поэтому, если отказаться, наконец, от вымученной части совместимости с C ("молчаливые" сужающие преобразования, столь же "молчаливая" обработка C-style cast, определение неинициализированных переменных без нужды и подобное), то сразу станет видно, на каком языке написана программа.

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

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

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

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

A>>Есть старое соглашение: если две строки кода написаны подряд, а комментарий — через вертикальный пробел, он относится ко всему блоку.

ЕМ>Если такое соглашение и есть, это лишь одно из множества разных соглашений, которые по факту являются соглашениями в относительно локальных группах. Ну и вряд ли стоит распространять стили кодирования формальных языков на естественные. Так недалеко до КГ/АМ, КД-ЧД и подобного.

Ты не поверишь...

https://rsdn.org/article/mag/200401/codestyle.XML#EIIAE

Соглашения по оформлению кода команды RSDN
...
Между группой комментариев и собственно кодом поставьте пустую строку. Это покажет, что комментарий относится к блоку кода, а не к конкретной инструкции. Напротив, если комментарий относится к конкретной инструкции, прижмите его вплотную к этой инструкции.

A>>Комментарий "+100500" относился ко всему блоку, а в первую очередь к "C++ на этой совместимости до сих пор паразитирует". Я видел крайне мало проектов, написанных на C++. Большинство написано на квазиязыке под названием "C/C++". И если бы от людей требовалось выбрать, C++ без C или C без C++, я бы на C++ не поставил.

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

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

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

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

В Си это делается при помощи пачки макросов IS_IN_SET2(), IS_IN_SET3() ... IS_IN_SETN(), связанных вариадическим макросом. Это ужасное решение, безусловно. Если написать такой код: https://stackoverflow.com/a/11763277/14400772, можно нечаянно вызвать Сатану. А если ещё заставить его работать в студийном компиляторе: https://stackoverflow.com/a/5134656/14400772, то можно разбудить Ктулху.

Но это РЕШЕНИЕ. А вот если сравнить его с самым лучшим предложенным плюсовым кодом (конечно же, на шаблонах), то. Начнём с того, что оно тоже очень корявое. Есть такое соглашение (среди создателей языков), что шаблоны это обобщения на типы, а не просто черезжопный интерфейс к препроцессору. Но плюсовики, как ты выше, делают удивлённые глаза: мы про такие соглашения ничего не слышали! Пусть это будет на их совести, но факт в том, что это, строго говоря, НЕ РЕШЕНИЕ. Очевидное условие — отсутствие паразитного call'а, потому что если ты на него согласен, хватит и простой перегрузки функций.

Мало того, что #define это по духу чисто сишный подход, так необходимая часть (__VA_ARGS__) ещё и не поддерживалась в плюсах аж 12 лет. При отсутствии альтернативы. Альтернативой был бы нормальный препроцессор, а не говно мамонта из языка Си. Вот поэтому и приходится смешивать старые и новые напластования: вариантов просто нет. Что, конечно, само по себе не очень хорошо.

А ты спрашиваешь, зачем в плюсы тянут совместимость с Си. Зачем в 11-ые плюсы, например, добавили вариадические макросы из Си99? По крайней мере, теперь можно хотя бы через сишные конструкции решить поставленную задачу. А кто не согласен, может показать сиплюсплюсное решение, с выполнением всех условий (отсутствием call'а в первую очередь).

ЕМ>Поэтому, если отказаться, наконец, от вымученной части совместимости с C ("молчаливые" сужающие преобразования, столь же "молчаливая" обработка C-style cast, определение неинициализированных переменных без нужды и подобное), то сразу станет видно, на каком языке написана программа.

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

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

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