LLVM/clang vs GCC

[waqur]

После того, как Столлманновские коммунисты от программного обеспечения, Free Software Foundation, перелицензировали компилятор GNU Compiler Collection под GPLv3, ряд коммерческих компаний, у которых действует политика no-gplv3-beyond-company-doors, оказались в затруднительной ситуации.

Для такой политики есть свои основания. GPLv3 предполагает передачу вместе с программным обеспечением не только исходников, но и всех надлежащих патентных прав; а также отказ от тивоизации и отказ от преследования взломщиков тивоизации в судебном порядке. С правовой т.з., такая расширенная область действия лицензионного соглашения меняет его субъектность с copyright law на contract law. Всё это не очень хорошо, и по этой причине ряд компаний, например Apple, подключились к финансированию фонда LLVM и начали с чистого листа разработку нового C-компилятора с более свободной лицензией (clang). Они фактически наняли на работу исследовательскую команду из университета Иллинойса, которая начинала работать над LLVM.

Также FreeBSD и другие BSD-системы заморозили обновление GCC. И в седьмой, и в восьмой версии системы версия компилятора есть GCC 4.2.1 20070719, и она уже никогда не сдвинется с мёртвой точки. Система, которая построена на медленно, но неотвратимо устаревающем компиляторе, обновления которого заклинило — это не фатально, но неприятно. Наконец, в FreeBSD 9, основным компилятором станет LLVM+clang. История развития clang доступна здесь.

Comments

[cd-riper.livejournal.com]

да, clang развивается очень быстро, что не может не радовать. плюс поздний старт проекта позволил в него заложить очень много вкусных особенностей (к примеру Qt Creator использует его в IDE для навигации по коду, подсказкам etc).

в свое время, развитие clang дало хорошего пинка под зад GCC, в том числе говорят о том, что именно скорость развития clang заставила разработчиков GCC начать использовать C++.

с другой стороны, в плане поддержки C++11 GCC пока что впереди планеты всей.

(Ёпт, опять пришлось исправлять)

[waqur.livejournal.com]

В LLVM сделали очень хорошую вещь: стандартизировали промежуточное представление.

Идея иметь единое промежуточное представление и заменить N компиляторов для M платформ (N*M) N фронтэндами + M бэкэндами не нова, но именно в LLVM она развернулась на полную мощь, учитывая привычку гнусятников менять формат промежуточного представления от версии к версии.

Это только на первый взгляд кажется, что всё просто: бесконечный регистровый файл, трёхадресный код, вызов/возврат, дело в шляпе, что там менять. На практике появляются: исключения, longjump'ы, interlocked-инструкции, alloca, вычисления с плавающей точкой, SIMD-инструкции, SEH/VEH, куча calling conventions. Все эти детали теперь в стандарте. Побочный эффект: жёсткая фиксация C++ABI на уровне GCC 4.2.1. Это всё задумывалось ради gcc/llvm совместимости, конечно же, но также она даёт и внутриверсионную совместимость LLVM. А гнусятники продолжают всё непрерывно менять и сосут банан.

------------------------------

Далее, в GCC накопились артефакты 15-летнего сопровождения кода. Когда последний раз его переписывали с нуля? При переходе от кафедральной к базарной модели разработки в версии 2.95? 15 лет сопровождения - это как раз тот срок, когда код на C/C++ надо выбрасывать и переписывать с нуля. Может для open source будет повышающий коэффициент типа 1.5, но всё равно LLVM лучше просто потому, что он новее.

------------------------------

C++11 это фактически отдельный язык. Лямбды, перемещения, часть буста в стандартной библиотеке - все эти вещи ещё ждут своих Мейерсов, Саттеров и Александреску. В среде Windows также ломается совместимость с NT 5.0, если мы используем Microsoft'овский компилятор для C++11 и его runtime-библиотеку. Также Microsoft'овская тактика EEE в отношении языка Си и его стандартной библиотеки, в особенности запор в компиляторе на уровне C89 тоже не способствуют прогрессу. Я думаю, что с переходом на C++11/C12 Microsoft предпочтёт остаться в стороне со связкой C++11/C89 и расклин между виндой и остальными платформами только расширится.

------------------------------

Быстрое добавление комментариев через AJAX внезапно перестало работать в ЖЖ. Опять сцуп что-то мутит?

Re: (Ёпт, опять пришлось исправлять)

[cd-riper.livejournal.com]

> стандартизировали промежуточное представление

ну, можно было подсмотреть на тот же MSIL, для которого можно в бекэнде делать типа JIT в инструкции целевой платформы.

> Когда последний раз его переписывали с нуля?

ну, ты сам понимаешь, плюсовый компилятор это ОЧЕНЬ дорогая программа, чтобы ее внезапно взять и с нуля переписать. вопрос скорее, делали ли своевременный рефакторинг, или сцали.

> но всё равно LLVM лучше просто потому, что он новее

да, да, именно это я и хотел сказать.

> C++11 это фактически отдельный язык

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

что касается Microsoft, WinRT, C++/CX и C++11 -- опять же заготовлен материал на отдельный большой и очень интересный пост по теме. там все не так просто и глядя на Саттера я верю, что он будет болеть за максимальную поддержку C++11 в MSVC (при том, что в VC11 нас ждет большой облом).

> Опять сцуп что-то мутит?

завтра, как всегда, будут рассказывать сказки про дидос. мине это все еще весной надоело, поэтому я и слали на другую платформу.

Re: (Ёпт, опять пришлось исправлять)

[cd-riper.livejournal.com]

> все эти вещи ещё ждут своих Мейерсов, Саттеров и Александреску

ты знаешь, для меня подавляющее большинство вещей в C++11 это то, что я давно ждал и они мне все как родные. мне не надо объяснять зачем они и что с ними делать. мне главное -- быстрее дайте!!

Re: (Ёпт, опять пришлось исправлять)

[waqur.livejournal.com]

Ну, все эти люди - это не столько евангелисты новых фич, сколько скептики.
Они пишут о том, что не надо использовать. Чего избегать.

К примеру, евангелистами C++98 был Страуструп. Ну и Степанов. Они навалили-навалили побольше и спрятались в кусты. Понадобилось боле пяти лет, чтобы это всё распробовать и сформулировать чёткие, подробные, аргументированные рекомендации относительно того, какие фичи не следует использовать и почему.

C++11 ещё ждёт своих гениев в области критики. Кстати говоря, не факт, что это будут те же самые герои.

Re: (Ёпт, опять пришлось исправлять)

[cd-riper.livejournal.com]

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

Re: (Ёпт, опять пришлось исправлять)

[waqur.livejournal.com]

Да, именно критики. Конечно, конструктивной - не КГ/АМ.

И кстати основной объём новой критики придётся на перемещения, я думаю. Я не уверен, как этот концепт накладывается на strict exception safety, срезку и другие вещи, которые обсуждались раньше этими авторами.

Всё это не так просто, когда начинает компоноваться друг с другом всеми возможными способами.

Re: (Ёпт, опять пришлось исправлять)

[cd-riper.livejournal.com]

перемещение это копирование значения указателя. какие исключения?
срезка для value типов это проблема лежащая вне move.

если какой-то сайд эффект и будет, то точно такой же эффект можно было поиметь от RVO.

[waqur.livejournal.com]

Кстати, уже сейчас есть мнение, что злоупотребление автоматическим выводом типов (новая трактовка ключевого слова auto) в C++11 - это антиидиома.

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

То, что хорошо работает в Go и других языках за счёт сборки мусора, в C++ может стать очередным способом отстрелить себе ногу. Запрет на auto в контексте вызова функций и другие новации в coding standards ещё ждут своих Мейерсов, как я уже писал выше.

[waqur.livejournal.com]

... ну и разумеется, зоопарк unique_ptr, scoped_ptr, shared_ptr и старого auto_ptr только усугубляет всеобщий п*здец

[cd-riper.livejournal.com]

auto_ptr используют только идиоты, которые с луны свалились.
нормальные люди используют boost::shared_ptr и boost::scoped_ptr, которые тупо через реплейс по тексту надо поменять на std::shared_ptr и std::unique_ptr.
scoped_ptr, как я понимаю, переименовали в связи с поддержкой move семантики.

[waqur.livejournal.com]

Ну вот, уже четверо - T*, const T*, std::shared_ptr<T>, std::unique_ptr<T>.

Что там с boost::weak_ptr?

С CComPtr / CComQIPtr / _com_ptr_t?

Наверное, в этом вашем хвалёном Qt не обошлось без парочки смарт-указателей с блэкджеком и шлюхами.

Оставим в покое указатели и возьмём строки. То же самое. Вернули в auto, сравнили или сплюсовали с литералом, какой там объект из этого литерала неявно сконструировался и через какой delete удалился при падении процесса в корку - это будет очень увлекательно выяснять каждый раз.

[cd-riper.livejournal.com]

auto то здесь при чем? оно и без auto будет вести себя совершенно так же.

[waqur.livejournal.com]

auto здесь при том, что с ним ты даже не поймешь, какая часть какого фреймворка замешана

есть auto и есть строковый литерал

что за этим auto? std::string? wxString? QString? _bstr_t? CComBSTR? список далеко не полон

[cd-riper.livejournal.com]

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

[waqur.livejournal.com]

А самый лулз будет там, где auto - это возвращаемый тип (шаблонные inline-функции). В сочетании с implicit-конструированием и перегрузкой это даёт такую гремучую смесь, что я даже боюсь представить, какой код наваяют индусы.

Будем делать и изучать дампы символьных таблиц компилятора, чтобы разобраться в этом навозе, не иначе.

[cd-riper.livejournal.com]

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

[waqur.livejournal.com]

мы уже обсуждали это раньше и пришли к выводу, что каша в голове не у меня, а у разработчиков компиляторов, которые вольно интерпретируют стандарты
http://cd-riper.livejournal.com/322621.html?thread=2174269#t2174269

я тебе демонстировал пример, как implicit conversion может отработать дважды в одном выражении, ну а теперь если добавить ещё auto в возвращаемых значениях и перегрузку, будет вообще весело

[cd-riper.livejournal.com]

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

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

[waqur.livejournal.com]

моё мнение о новом стандарте - "здоровому не нужно, больному не поможет" :)

[cd-riper.livejournal.com]

да, злоупотребление auto до добра не доведет, но вполне понятно для чего именно это решение предназначено -- получение итератора для развестистого контейнера, результат boost::bind, лямбда etc.

и да, те, кто код пишут в современных IDE, а не FAR'ах, могут всегда навести курсор мыши на метод и посмотреть что он возвращает :)

[waqur.livejournal.com]

не всё так просто: есть перегрузка, есть неявное преобразование типов, некоторые функции зависят от шаблонов и эта зависимость может пускать перегрузку разными путями при разных значениях шаблонного аргумента

все эти твои хвалёные IDE усрутся, пока перелопатят последний h-файл, чтобы предложить мне все варианты :)

[cd-riper.livejournal.com]

ты рассматриваешь экстремальный случай.

на самом деле, в жизни все идеально работает в 99.9% случаев. с помощью того же clang.
и лопатят не на лету -- для многих вещей базу строят предварительно.

[waqur.livejournal.com]

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

некоторые вещи в программе достаточно поменять совсем чуть-чуть, чтобы 50% этой базы стали мусором (типа, эффект бабочки)

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

[cd-riper.livejournal.com]

да, да, продолжай сидеть в FAR'е и ни в коем разе не используй лямбды и auto! :)

[waqur.livejournal.com]

Да что там FAR -- люди до сих пор в vi и emacs сидят.

Лямбды и auto надо бы сначала обкатать в пилотном проекте. Или почитать умных людей. Когда им будет, что написать. :)

[cd-riper.livejournal.com]

как можно сравнивать emacs и FAR?

в тестовых проектах все работает просто замечательно.
и Майерс вон уже книгу выдал.

[waqur.livejournal.com]

А если я сделаю шаблончик типа

template<std::size_t N>
    class C
    {
        public:
            C<N+1> operator->();
    };

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