> О, ну вот уже пошёл относительно конструктивный диалог на втором десятке комментариев
> в ветке.mea culpa. забыл, что телепаторы ещё не изобрели.
> При этом предметы быть равными не обязаны, и
> кланги всякие с гцц этому вполне удовлетворяют, ИМХО.
если сравнивать, скажем, как реализована поддержка некоего языка, или насколько хорош кодогенератор — вполне. а вот если сравнивать архитектуру — то сначала надо доказать, что архитектура gcc (ну да, мягко говоря, не образец красоты) стала такой только и исключительно потому, что хреново спланирована. а чтобы это доказать, надо реализовать в другом проекте всё то же самое, что умеет gcc, и как минимум на том же уровне (в том числе и кодогенератор, который должен быть по всем параметрам как минимум не хуже, чем у gcc). «теоретически оно может и ничего не препятствует, и особо менять ничего не надо» — не катит. теоретически много чего можно, а на практике начинают лезть подводные камни, из-за которых, в том числе, в архитектуре иногда появляется хтонический ужас.
> А что до читерства - ну это как школьники в онлайн-стрелялках, право
> дело. Как только тебя чуть убили или ещё что, сразу кричи
> про читерство.
так вопрос же не в том, кто победит, вопрос в том, что иначе сравнение не имеет смысла: нечто с обрезаным фичсетом почти всегда можно сделать лучше и понятней, чем с необрезаным.
> Во-первых, тогда давай рассматривать не такие фичи, как «поддержка ATTiny23 и S/390»,
> а просто «кроссплатформенность».
нет. именно поддержка *всех* платформ, которые умеет gcc.
> Для ответа на вопрос выше о том, лучше
> ли архитектура потому, что руки и мозги у разработчиков прямее, этого
> хватит, потому что 5 или 50 платформ поддерживает компилятор, уже не
> столь принципиально, если он вообще способен генерировать код под более чем
> одну платформу.
принципиально. тут пример с VLIW уже приводили. штука в том, что разные архитектуры могут иметь разные «бзики». у кого-то какой-то регистр только вот так использовать можно, а так нельзя — и опа! в регистровом аллокаторе появляется костыль для этой архитектуры. у кого-то вот такая последовательность команд работает медленней, чем вот нетакая — и опа! в кодогенераторе появляется костыль со специальным случаем. и так далее.
вот именно потому я и говорю, что сначала надо реализовать всё, в полной мере и как минимум не хуже — чтобы все эти костыли на место воткнуть. и тогда уже посмотреть, что осталось от изначально красивого и изящного API с кодом.
> А вот что новые фичи в плане стандарта запиливаются систематически быстрее, чем
> в случае gcc, это вот хороший и позитивный знак, например. И
> в ряде приложений это куда важнее.
и это никак не отвечает на вопрос «лучше и проще ли было переделать gcc с нуля». потому что, например, запиливаться быстрее они могут именно потому, что у llvm местами обрезаный (по сравнению с gcc) фичсет. см. выше про всякие костыли.
> Хорошо, llvm с gcc сравнивать нельзя, а gcc-то с llvm можно хоть?
> Или вообще ни один компилятор ни с каким другим сравнивать нельзя,
> и вообще ничего сравнивать нельзя?
> Это, если что, ирония над тем, что твои слова звучат как «если
> вещи разные, то их сравнивать нельзя». А нахрена сравнивать одинаковые вещи?
см. выше. одинаковые по выхлопу вещи можно делать разными путями. вот пути и есть смысл сравнивать. но чтобы эти пути сравнивать — сначала выхлоп должен быть одинаковый. в данном случае «одинаковый» — это все архитектуры, и на каждой у нового проекта код должен быть как минимум не хуже, чем у старого проекта. потому что если код хуже — опять не ясно: может, он хуже как раз потому, что в старом проекте всунули мегакостыль в оптимизатор, который уродливый, но зато делает код чуть лучше?
