> Значит вы считаете, что качество кода - это по вашему не так
> важно по сравнению с его скоростью.

В моем понимании, качество кода имеет 2 основные метрики:
1) Размер кода (меньше==лучше)
2) Скорость кода (больше==лучше).

Эти метрики могут немного мешать одна другой, так что чем лучше компилер их сочетает - тем он лучше генерит код.

> - это по прежнему единственный показатель качества, который вы знаете.

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

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

Еще можно упомянуть что удобно когда тулчейн знает и умеет много разных наборов команд для разных процессоров. Это экономит силы программистам при кросскомпиле и прочая. Но все это не про clang, там сносно поддерживается только х86. И с большим скрипом - некоторые подтипы ARM.

> Ах, вот оно как оказывает - рюшки и бантики в вашем понимании
> - это и есть то самое качество кода, не считая скорости.

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

> Именно так вы понимаете качество - рюшки и бантики.

Удивительно наглая попытка передернуть. При том - профессионала в вопросах качества, что делает это просто EPIC FAIL'ом и однозначно детектирует фанбоя марки.

>> А вот хреново оптимизированный код - это плохо. Это по простому не лечится.
> Интересно, что в вашем понимании мешает оптимизировать неоптимизированный код

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

> И из какого это вы пальца высосали, что это "по простому не лечится".

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

> А вот что вы будете делать с некачественным кодом? Пусть даже оптимизированным.

Горбатая попытки передерга. Компилер лишь генерит код из того что написал програмер. Качество кода он сам по себе вообще никак не улучшает. Ну то-есть он может детектировать те или иные ошибки и подозрительные места, но это уже больше рюшечки. Потому что для продвинутого анализа кода можно и внешние тулзы натравить. Плюс ревьюить принимаемый в проект код живыми опытными програмерами, что всяко лучше. Так что подобные вещи уже больше именно к рюшечкам относятся.

> вашем понимании код сразу станет качественным.

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

[бред и попытки мне что-то там приписать заскипаны]

> Ну то есть вы подтверждаете, что это подобные варианты применения компьютерных программ
> - это единственно, что вы знаете об их использовании - ждать,
> когда вы что-то получите от компьютера, а потом вручную что-то сделать с результатом.

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

> Тогда конечно - скорость будет самый главный фактор. Хотя вы только что
> подтвердили, что у всех борцов за скорость именно такие представления об
> использовании программ.

Представления очень простые: машин не напрягает ждать человека. А вот человеков напрягает ждать машины. Поэтому вот так. Даже если 99% времени машина ждет человека, а человек ждет машину 1% времени, именно это ожидание будет человека раздражать. Человек не должен ждать машину. По возможности нигде и никак. С точки зрения идеального юзабилити в идеальном мире. В реальном мире это конечно возможно не всегда. Но стремиться к этому идеалу надлежит.

> То есть в вашем понимании компилятор это нечто неуправляемое и непредсказуемое.
> Но скорость для вас по-прежнему превыше всего.

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

> Далее. Вы даже не в курсе, что clang генерит код быстрее, чем
> gcc, то есть предмет разговора вы тоже не знаете.

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

> Ну и еще одна небольшая дополнительная ремарочка: вы, значит, уверены, что компилятор
> сделан именно из железа.

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

[философстсвования с попыткой сделать умную мину лица заскипаны]

> обычно замкнуто вокруг скорости. Спасибо, что вы это подтвердили на вашем личном примере.

Как вы понимаете, чем быстрее и компактнее генерит код компилер, тем при прочих равных програмер будет реже соваться в профайлер и прочая. Нет, конечно идиотизм в выборе алгоритмики это не вылечит, но в целом проблем у програмера на пути к его целям будет меньше. И это хорошо. Потому что програмер хочет проект сделать. А не попрыгать по всем мыслимым типам грабель, почитать невъ.... простыни асма, позеленеть недельку в профайлере и прочая. Чем всего этого меньше - тем лучше. Хорошая кодогенерация тому способствует.

> Ну, да. "Работает же!" - девиз всех быдлокодеров.

Итого: ваше сообщение содержит много воды, философствования, передергов и ... и ни одного конкретного аргумента насчет того что шланг делает лучше других. Epic fail. Сразу видно фаната марки.

Краткий пересказ вашего бреда в переводе на русский: "Мой фетиш рулит потому что рулит, а кто не понимает этого - те дураки! Какая еще скорость? Какой размер кода? Не, не слышали! Зато у нас генерится расово верный код! Не то что у этих быдлокодеров!"