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

A>когда пишущий на C++ прибегает ко встроенному Си

Это бессмысленная формулировка. Нет в C++ никакого "встроенного Си" — есть только конструкции, "унаследованные от C", "совместимые с C" и т.п. Иначе придется признать, что использование любых фундаментальных типов (кроме bool), и любой арифметики над ними, операции присваивания, точки с запятой и прочего — это "прибегание ко встроенному Си".

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

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

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

A>Этот пример достаточно типовой, чтобы его привёл автор исходной статьи, тот который из PVS.

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

A>медицина в эту сторону не копает. Знаешь, почему? Официальный ответ: это не нужно.

Это Вы теорий заговора начитались. Медицина в эту сторону копает с 80-х — то есть, со времен, как только вирус был выделен. Но все прогнозы пока неутешительны. Даже с вирусом простого герпеса, который куда сильнее локализован, пока справиться не могут — слишком сложно.

A>Пока ты принимаешь антиретровирусную терапию, ты будешь здоров (не разовьётся СПИД, не сократится жизнь и т.д.).

Угу, а когда у тебя (или у твоего государства) нет денег на достаточное количество препаратов, ты не принимаешь АРТ. И все, у кого тоже нет денег (или кого не смогли заставить), тоже не принимают. Но они (внезапно) не берут на себя обязательства поддерживать строгий моральный облик, и активно участвуют в распространении вируса.

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

A>Врачи не очень заинтересованы в том, чтобы люди были здоровы. Они заинтересованы в том, чтобы люди лечились.

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

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

Судя по активности рекламы того же PVS-Studio, его не очень-то покупают. Я, например, этими анализаторами вообще не пользуюсь.

A>каком виде надо записывать такие сравнения, чтобы эта ошибка стала невозможной?

"Ни в каком, бл#! Теперь — в твердом переплете".

A>Как выработать здоровую привычку для здорового кода? Такую, как Йода-сравнения, например.

В таких привычках нет ничего здорового. Это просто очередной кривой костыль, на безрыбье. С тех пор, как компиляторы начали выдавать предупреждения на потенциально опасное присваивание (где-то с 90-х, если не ошибаюсь), это задомнапередное сравнение полностью потеряло смысл.

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

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

A>Его раздули до недопрепроцессора

Что значит "до недопрепроцессора"? Любой препроцессор в ЯВУ — по определению убогий костыльный инструмент, применяемый от безысходности, когда нет ресурсов делать адекватный анализатор/генератор кода, а работать надо. Что сишний, что плюсовый — яркие примеры принципа "нет ничего более постоянного, нежели временное".

A>а других инструментов шаблонизации не дали (ну и остались устаревшие инструменты из Си). Но мне лично это не кажется правильным.

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

A>потому, что приведённая в пример задача этим инструментом, как я понял, не решается.

Как и многие другие, куда более актуальные. Хотя даже не сомневаюсь: если заинтересовать ею "шаблонных хакеров" во главе с Александреску, Степановым и иже с ними, через некоторое время они родят внешне приемлемое решение, но вот реализацию его будет лучше не смотреть на ночь.

A>Оптимизаторы массово посходили с ума, и творят страшные вещи. Это касается теперь и Си, к сожалению.

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

Собственно, унихоиды сами загнали себя в эту ловушку, поставив во главу угла исходные тексты, вместе с крайней желательностью (а зачастую — и необходимостью) собирать их заново в каждой отдельной системе. Пока у C не было стандартов, исходники набивались #if'ами, учитывающими особенности отдельных реализаций компилятора/линкера. С появлением стандартов стало возможным избавиться от части условий, но тут (внезапно) выяснилось, что стандарты не одобряют хаков. А среди сишников-унихоидов как раз довольно много тех, у кого "это моя программа! это моя машина! не сметь диктовать мне, что я могу делать, а что нет!". Но они ж пишут не только для себя, однако привычки настолько укореняются, что контролировать их непросто.

A>они могут и для явно записанных пар сравнений сгенерировать функцию и её вызов.

Если это хотя бы не менее эффективно, чем последовательный код — почему нет? А если вдруг менее, то с какой стати оптимизатору намеренно ухудшать эффективность?

A>чтобы с этими волками жить, надо по-волчьи выть. А именно, писать тот код, который максимально чётко показывает, что ты хочешь.

Дык, волки тут ни при чем — к такому имеет смысл стремиться всегда и везде, независимо от. Чем более ясно выразишь свои идеи и намерения, тем выше вероятность, что тебя поймут правильно. Именно к этому я всегда и призываю в развитии любых ЯП. И для этого вовсе не обязательна "исходная" многословность, вроде паскалевских begin/end — запись может быть и лаконичной, лишь бы была возможность развернуть ее в удобночитаемую форму при нужде.

A>И если оптимизирующий компилятор сделал что-то, чего ты не хочешь, надо ругаться с автором компилятора. Так делает Линус, так делают разные программисты из статьи, на которую я дал ссылку.

Логично. Поэтому очень желательна возможность управления оптимизацией на "тонком" уровне, а не только через ключи компилятора.

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

На этот случай в популярных реализациях есть атрибуты вроде __forceinline. По-хорошему, их лучше бы внести в стандарт, но "коллектив авторов", среди которых почти сплошь прикладники-абстракционисты, будет активно возражать.

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

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

A>Кастинги мне нужны как в Си, точка. По очень многим причинам, я их не буду здесь перечислять.

А было бы интересно. У меня не самые примитивные программы, но от преобразований что в стиле C, что в "функциональном" плюсовом, я избавился достаточно давно, и никаких сколько-нибудь заметных напрягов это не потребовало.

A>Если "пометка в тексте программы" это X_cast<T>, то неважно, что об этом думаю я, это будет конец паразитированию на Си и, как я сильно подозреваю, конец мифу о популярности C++.

Еще интереснее. Что ж и Вы, и другие "паразиты", такого делаете, что переход на X_cast<> может заставить Вас отказаться от языка? У вас эти преобразования в каждой второй строке? Или хотя бы в каждой пятой?

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

Увы, я по-прежнему не могу понять, о чем именно идет речь.

A>и Си уже не тот. Си теперь тоже дофига высокоуровневый.

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

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

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

A>или виртуальная машина (CLR, JVM, V8 и т.п.) и гарантия отсутствия проблем с памятью, или ответственность на мне, но я должен понимать, что происходит, и контролировать ситуацию.

Промежуточные варианты не рассматриваются? Например, возможность привязки к конкретным реализациям VM, или автоматизация управления памятью?

A>Если я объявил переменную, но не проинициализировал, значит под неё выделилась память, и она содержит всякую фигню. Всё, дальше я сам.

Почему не возникает резонного вопроса "как построить программу так, чтобы объявить переменную, но не инициализировать ее, было технически невозможно"? На худой конец — чтобы компилятор был обязан обнаруживать все подобные ситуации, и генерировать ошибку (а не предупреждение), если переменная в тексте явно не снабжена хорошо заметной пометкой типа "да, я нарочно объявил ее здесь, и буду за это отвечать". Тогда что компилятор, что внешний анализатор, могли бы для любой программы показать список таких пометок, чтоб при поиске причин глюков знать, куда смотреть в первую очередь.

A>Если я что-то делаю с указателем, то делаю что-то с указателем. Иначе возникает ситуация, когда компилятор меня ограничивает, но ни за что не отвечает.

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

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

Совершенно верно: зумеры хотят, чтоб все стало как можно проще, зубры хотят, чтоб все осталось, как раньше. Вместо того, чтобы искать разумный компромисс, обе стороны уперлись в "нет, должно быть только по-нашему, и никак иначе".