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

ЕМ>Вы меня точно ни с кем не путаете?

Давай считать, что я привёл неудачное сравнение.

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

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

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

ЕМ>Тут нужно начать с того, что задача именно в таком виде не является достаточно типовой, чтобы иметь в языке какие-то свойства именно под нее.

Во-первых.

Я привёл пример на тему, когда пишущий на C++ прибегает ко встроенному Си, и почему. Эти примеры я могу приводить и дальше, а этот выбрал потому, что он рядом, в этом же форуме, его все видели, и настоящие эксперты (не то, что я) привели какие-то решения, высоко оценённые другими экспертами.

Во-вторых.

Этот пример достаточно типовой, чтобы его привёл автор исходной статьи, тот который из PVS. То есть, это вообще не мой пример. Мой вклад тут в том, что я переформулировал задачу исходя из интересов программиста, а не компании PVS.

Маленький оффтопик. Я тут читал статью про лечение ВИЧ. Есть несколько случае полного излечения, когда следов вируса не обнаруживается много лет. Но медицина в эту сторону не копает. Знаешь, почему? Официальный ответ: это не нужно. Пока ты принимаешь антиретровирусную терапию, ты будешь здоров (не разовьётся СПИД, не сократится жизнь и т.д.). То есть, ты здоров, пока работаешь кошельком для фармацевтов. Удобно, да? Врачи не очень заинтересованы в том, чтобы люди были здоровы. Они заинтересованы в том, чтобы люди лечились.

Вот и авторам статических анализаторов не нужно, чтобы ты писал здоровый код. Ведь тогда анализаторы перестанут находить у тебя ошибки, а ты перестанешь их покупать. Поэтому, увидев совет пользоваться форматированием (которое особо не спасает), я переформулировал эту задачу так: в каком виде надо записывать такие сравнения, чтобы эта ошибка стала невозможной? Как выработать здоровую привычку для здорового кода? Такую, как Йода-сравнения, например. Вот и всё. А сама ошибка достаточно типовая, чтобы автор PVS её рассмотрел в своей статье.

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

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

Шаблонизация должна быть обобщением на всё, что может потребовать шаблонной обработки. А конкретно template это один из инструментов шаблонизации. Изначально он вообще весь был вокруг typename. Его раздули до недопрепроцессора, а других инструментов шаблонизации не дали (ну и остались устаревшие инструменты из Си). Но мне лично это не кажется правильным. Почему? Да потому, что приведённая в пример задача этим инструментом, как я понял, не решается. Чтобы не начинать заново, типичная она или нет, я сразу скажу, что миллион таких задач приведу.

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

ЕМ>inline не спасает?

https://en.cppreference.com/w/cpp/language/inline

The original intent of the inline keyword was to serve as an indicator to the optimizer that inline substitution of a function is preferred over function call, that is, instead of executing the function call CPU instruction to transfer control to the function body, a copy of the function body is executed without generating the call. This avoids overhead created by the function call (passing the arguments and retrieving the result) but it may result in a larger executable as the code for the function has to be repeated multiple times.

Since inline substitution is unobservable in the standard semantics, compilers are free to use inline substitution for any function that's not marked inline, and are free to generate function calls to any function marked inline. Those optimization choices do not change the rules regarding multiple definitions and shared statics listed above.

То есть, и раньше ничего не гарантировалось, а теперь и подавно.

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

А если ты явно описываешь функцию, пусть даже помеченную inline, то ругаться уже бесполезно. Тебя ткнут носом в стандарт, и спросят, на что ты жалуешься.

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

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

Это уже спор о терминах. Я имел в виду именно это.

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

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

Я подозреваю, это вопрос из серии "Вы любите тёплое пиво и потных женщин?" с последующим отпуском в ноябре. Конечно же, ответ будет — смотря о чём речь. Кастинги мне нужны как в Си, точка. По очень многим причинам, я их не буду здесь перечислять. Если "пометка в тексте программы" это X_cast<T>, то неважно, что об этом думаю я, это будет конец паразитированию на Си и, как я сильно подозреваю, конец мифу о популярности C++.

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

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

Какие ты привёл примеры ("столь же "молчаливая" обработка C-style cast, определение неинициализированных переменных без нужды и подобное"), на то я и ответил.

Другое дело, что и Си уже не тот. Си теперь тоже дофига высокоуровневый.

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

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

Не знаю, как большинство (или там сиплюсплюсные меньшинства), а я смотрю на ситуацию так. Есть два разумных варианта: или виртуальная машина (CLR, JVM, V8 и т.п.) и гарантия отсутствия проблем с памятью, или ответственность на мне, но я должен понимать, что происходит, и контролировать ситуацию. Если я объявил переменную, но не проинициализировал, значит под неё выделилась память, и она содержит всякую фигню. Всё, дальше я сам. Если я что-то делаю с указателем, то делаю что-то с указателем. Иначе возникает ситуация, когда компилятор меня ограничивает, но ни за что не отвечает.

Ещё раз: это, к сожалению, в полной мере применимо и к старому доброму Си, как его теперь видят зумеры. Это не эксклюзивно проблема С++.