Здравствуйте, Alekzander, Вы писали:
A>Это пример из проекта, где is_in_set() встречался буквально десятками.
Я правильно понимаю, что Вы одобряете использование множественных сравнений "десятками", без стремления преобразовать их в более адекватный вид (switch, таблицу или битовые маски), и выступаете лишь за то, чтобы подобный кондовый код писали и дальше, лишь бы делали в нем меньше опечаток?
A>Эта теория заговора называется "рыночная экономика". Фармкомпании вкладывают деньги в то, что принесёт деньги, быстро и много.
Какие-то компании вкладывают деньги иначе?
А фармкомпании вкладываются в разработку АРТ прежде всего потому, что есть госзаказы на нее, объем которых значительно больше, чем совокупность индивидуальных. Они и стабильнее, и расценки там можно предложить выше. Так вот получилось, что препараты для достаточно эффективной АРТ удалось создать раньше, чем препараты для полного излечения. На этом безрыбье любому государству выгоднее сдерживать у себя эпидемию с помощью АРТ, чем ждать, пока сделают радикальную терапию.
Тем не менее, над радикальной терапией продолжают работать, и достаточно интенсивно. Просто потому, что АРТ ни разу не безвредная — она лишь заменяет относительно скорую и весьма неприятную смерть от СПИДа более длительной, но не слишком приятной жизнью на АРТ. Мало у кого получается сидеть на АРТ и продолжать безмятежно радоваться жизни.
A>Ты явно не читаешь обзоры этого бизнеса.
Я не читаю текстов, у которых явно прослеживается цель создания определенной точки зрения и/или позиции у читателя.
A>Записав код как foo(v, 1, 2, 3), ты больше не сможешь пропустить v ==.
Но по-прежнему смогу сделать десятки-сотни других ошибок, в том числе логических и неочевидных.
A>Да, это всё, чего мы добились.
Именно — изощренными приемами, к которым есть резонные вопросы (тот же возможный вызов) понизили вероятность отдельно взятой ошибки, при том, что эту самую вероятность никто не оценивал. То есть, внезапно обнаружили, что есть какой-то риск, и приняли активные меры для того, чтобы этого риска избежать. А о том, что рядом могут быть (и, скорее всего, есть) гораздо более высокие риски, предпочли не думать. Это распространенный подход — предотвращать не то, что наиболее вероятно, а то, что почему-то больше всего пугает.
A>А я вот ещё недавно собирал плюсовую программу под одну железяку очень специальным компилятором, который ворнингами не баловал.
Если Вы эту программу не писали специально под эту железку, и код более-менее переносимый, то его правильность можно проверять более умным компилятором. А если именно специально под нее, то сколько можно найти таких компиляторов? Ну не повезло конкретно Вам, зачем же отстаивать приемы, которые для большинства давно потеряли актуальность?
A>если у тебя в одном проекте код на плюсах и каком-нибудь интерпретируемом DSL, тебе лучше выработать здоровую привычку всегда писать единообразно.
Хм, и сколько таких DSL, где можно писать код "единообразно" с плюсовым, чтоб это не просто было в одном стиле, а действительно уберегало от ошибок?
A>А я советую прочитать примеры, которые они приводят.
Читал я подобные переписки. В одном, помнится, дошли аж до возмущения тем, что в цепочечном сравнении вроде Вашего оптимизатор вставил ветвление, которое "снижает быстродействие", а не преобразовал выражение так, чтобы обойтись арифметикой и логикой. И никто ведь не вспомнил, что компилятор, по-хорошему, вообще не имеет права вычислять правые выражения до того, как будут получены и проверены результаты левых.
Повторю: бороться нужно не с оптимизациями, как таковыми, а с их неочевидностью. То есть, настаивать на поддержке в языке (или хотя бы в компиляторах) средств, позволяющих избежать нежелательных оптимизаций. На худой конец — чтоб компилятор предупреждал, что конструкция кажется ему бессмысленной, и он как-то редуцирует.
ЕМ>>Логично. Поэтому очень желательна возможность управления оптимизацией на "тонком" уровне, а не только через ключи компилятора.
A>Если ты в явном виде вставил вызов функции, ты больше не можешь жаловаться, что оптимизатор сгенерировал call.
Если я вставил вызов функции с __forceinline — могу.
A>__forceinline нужен не для этого случая, лол. А для случая, обратного ему.
Я запутался в Вашей логике. Вы начали с опасения о том, что вызов функции не развернется в код в точке вызова, а будет сгенерирован call, и inline не гарантирует непосредственной вставки. Я предложил __forceinline, но "это снова не то". А что нужно-то?
Для "случая, обратного ему" VC++ есть __declspec(noinline). Вроде и у GCC тоже такое есть.
