Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я бы сказал, что в вашем обсуждении народ просто развлекался для разминки мозгов. Одни это любят, другие не понимают. Я вот тоже считаю, что напрягаться для решения задачи имеет смысл, когда задача возникла более-менее естественным путем, а не когда ее создали искусственно. В жизни и так хватает задач, которые возникают сами собой, чтобы отвлекаться еще и на решение специально созданных — напоминает анекдот про гамак и лыжи. 
Я же не виноват, что ты видел мало кода в своей жизни.
Эти сравнения сплошь и рядом встречаются, например, при поддержке железа. Вендор выпустил модельную линейку, в которой у каждой модели уникальный профиль поддержки багофич, ты в рантайме запросил ModelId и вперёд. Это пример из проекта, где is_in_set() встречался буквально десятками.
Збс, конечно. "Я не видел, значит это никому не надо".
ЕМ>Это Вы теорий заговора начитались. Медицина в эту сторону копает с 80-х — то есть, со времен, как только вирус был выделен. Но все прогнозы пока неутешительны. Даже с вирусом простого герпеса, который куда сильнее локализован, пока справиться не могут — слишком сложно.
Эта теория заговора называется "рыночная экономика". Фармкомпании вкладывают деньги в то, что принесёт деньги, быстро и много. Ты явно не читаешь обзоры этого бизнеса.
A>>каком виде надо записывать такие сравнения, чтобы эта ошибка стала невозможной?
ЕМ>"Ни в каком, бл#! Теперь — в твердом переплете".
Мне уже понадоела шымжа-стайл философия, если честно. Записав код как foo(v, 1, 2, 3), ты больше не сможешь пропустить v ==. Да, это всё, чего мы добились. Кофе такой код не варит, ото всех болезней не лечит, на бирже не торгует, в ж не целует. Он не нужен.
A>>Как выработать здоровую привычку для здорового кода? Такую, как Йода-сравнения, например.
ЕМ>В таких привычках нет ничего здорового. Это просто очередной кривой костыль, на безрыбье. С тех пор, как компиляторы начали выдавать предупреждения на потенциально опасное присваивание (где-то с 90-х, если не ошибаюсь), это задомнапередное сравнение полностью потеряло смысл.
Хорошо, когда ты все компиляторы повидал. А если чего-то и не видал, то в этом нет смысла.
А я вот ещё недавно собирал плюсовую программу под одну железяку очень специальным компилятором, который ворнингами не баловал. Не говоря уж о том, что если у тебя в одном проекте код на плюсах и каком-нибудь интерпретируемом DSL, тебе лучше выработать здоровую привычку всегда писать единообразно.
ЕМ>Как и многие другие, куда более актуальные. Хотя даже не сомневаюсь: если заинтересовать ею "шаблонных хакеров" во главе с Александреску, Степановым и иже с ними, через некоторое время они родят внешне приемлемое решение, но вот реализацию его будет лучше не смотреть на ночь.
Вот это точно.
A>>Оптимизаторы массово посходили с ума, и творят страшные вещи. Это касается теперь и Си, к сожалению.
ЕМ>Подобные тексты советую читать с изрядной долей скептицизма. Их авторы традиционно путают особенности реализаций, которые зачастую бывает удобно и полезно использовать именно для конкретных платформ, с условной "С-машиной", которую описывает стандарт. Они хотят странного — чтоб стандарт одновременно обеспечивал и неограниченную переносимость, и предельную эффективность любой конкретной реализации, и чтоб нигде не возникало UB. А это принципиально невозможно — либо абстракция, либо конкретика, третьего не дано.
А я советую прочитать примеры, которые они приводят. Переписки, в т.ч. Если раньше скандалов с хипстооптимизаторами не было, а сейчас они есть, значит что-то изменилось.
ЕМ>Логично. Поэтому очень желательна возможность управления оптимизацией на "тонком" уровне, а не только через ключи компилятора.
Такая возможность в данном случае называется "явный (не)вызов функции". Если ты в явном виде вставил вызов функции, ты больше не можешь жаловаться, что оптимизатор сгенерировал call.
ЕМ>На этот случай в популярных реализациях есть атрибуты вроде __forceinline. По-хорошему, их лучше бы внести в стандарт, но "коллектив авторов", среди которых почти сплошь прикладники-абстракционисты, будет активно возражать.
__forceinline нужен не для этого случая, лол. А для случая, обратного ему. Его, конечно, хорошо было бы стандартизировать. А кто тут абстракционист, советую перечитать свою философию про "только дурак будет пользоваться системой, защищающей от ошибок" в ответ на конкретный вопрос.
