Будущее g++

если рядом должен быть установлен Шланг

Мир ограничен машинками разрабов с IDE?

Докладываю:

с++ Мир ограничен машинками разрабов с IDE!

Шланг уже научился в нормальную кодогенерацию в отладочном режиме или там всё ещё куча оптимизаций? А оставлять для отладчика хотя бы половину той информации, что сохраняет G++? А кучу платформ, в которые он никогда не умел или которые уже дропнул?

Как уже сказали не надо ограничиваться completion-driven development и думать, что оно имеет какую-то существенную ценность. То, что IDE с clang могут сжирать гигабайты оперативы это нифига не преимущество.

Это как спрашивать зачем пилят OpenOffice, а не LibreOffice.

Шланг решил эту проблему, дав возможность комфортного, крестового кодописания

Здесь логическая ошибка. Не существует комфортного крестового кодописания, бывает только менее мучительное и более мучительное. А причина этому, кроме дичайшей перегруженности фичами, заключается в кривом синтаксисе и семантике, которые нельзя до конца корректно разобрать без прохождения половины этапов компиляции (читай «очень долго даже для масштаба 100-200 тыс строк»).

Если честно, то компилю через g++. Ну как это же какое-то КОСТЫЛИЩЕ - держать два с++ компилятора. Заморозить g++ как xorg, и вложить все силы в шланг, вроде логично было бы.

Держу десяток разных компилеров, зависимость есть.

нет, сlang это не форк gcc. Там полно различий…

Вот более правильные сравнения:

«Зачем пилят LibreOffice когда есть OnlyOffice?»

«Зачем пилят KDE когда есть Gnome?»

Логичнее было бы выдавать из G++ больше информации по AST. Тут меньше работы, оно там всё равно есть. Но как бы они не по идеологическим причинам воздерживаются от этого.

Ага, и запилить g++ в виде либы, по аналогии с libclang

Заморозить g++ как xorg, и вложить все силы в шланг, вроде логично было бы

А разве эти два компилятора не являются уже зрелыми и полнофичастыми? Какие там еще силы нужно вложить? Портировать на новую платформу? Я не вижу новых платформ. C++20? Читая ту дичь, которую они предлагают, я думаю, что скорее всего большая часть будет вырезана, по крайней мере из того, что касается самого компилятора, а не библиотек. В этом плане я одобряю C++17, который вычистил солидное кол-во мусора — капля в море, но всё же.

зачем пилят OpenOffice

Кстати, зачем?

Блин, да оба хорошие компиляторы. До выхода Clang - GCC ваще какое-то старьё выдавали, концентрируясь на всяких fortran и прочем говне, не пиля новые фичи, не внедряя поддержку новых арзитектур типа ARM, все эти кросскомпиляции у GCC каким-то хером тупили и настроить всё было очень не тривиально во времена iPhone 3G

даже LibreOffice уже не пилят!

Дейсвительно, какой год уже на дворе. Он же не в браузере.

Если уже пилить опенсорс, то хоть NextCloud. А в идеале что-то не на Apache/PHP

Зачем вообще gcc тратит силы на g++, может лучше вообще забросить и отдать кресты в руки шланга?

А с какой стати? Компилятор обязан компилировать, а не быть какой-то расширяемой хренотенью (как clang-llvm). g++ с задачей компилирования справляется.

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

а не быть какой-то расширяемой хренотенью

Ось, тоже должна работать, а не быть какой-то расширяемой хренотенью. Все срочно перекатываемся на оффтопик, SZT все разложил по полочкам!

ГыЦэЦэ старпёрился пока шланг не начал взлетать. Вот что конкуренция животворящая делает! Так что хорошо, что есть альтернативы. Пусть оба будут.

Ось, тоже должна работать …

… а не телеметрию передавать.

clang какие-то толстые бинари генерирует, libxul.so у firefox: clang + lto = ~116Mb, g++ + lto = ~80Mb. (gentoo)

Вот честно, читая новости на опеннете про новые версии Go или Rust и глядя там на примеры кода я каждый раз прихожу к мысли, что синтаксис плюсов в сравнении выглядит крайне понятным и читаемым

Вопрос привычки. После С-подобного синтаксиса выглядит сложно, соглашусь. Но если знаешь любой язык семейства ML, Haskell, или даже тот же Pascal, то Rust читать будет несложно.

А еще, по сравнению с крестами, синтаксис любого «нового» языка выглядит куда более единообразным.

Вот честно, читая новости на опеннете про новые версии Go или Rust и глядя там на примеры кода я каждый раз прихожу к мысли, что синтаксис плюсов в сравнении выглядит крайне понятным и читаемым

У тебя синдром утёнка — переписанные на расте с крестов небольшие программы выглядят на обоих языках плюс-минус одинаково:
https://github.com/dmitryikh/rust-vs-cpp-bench/tree/master/

Но если знаешь любой язык семейства ML, Haskell, или даже тот же Pascal, то Rust читать будет несложно

Ну я умею в паскаль и хаскель, а дальше что? Паскаль читать очень просто, хаскель читать очень сложно при условии, что ты заранее наизусть не заучил всех хитромудрости конкретных используемых библиотек. В MTL, например, простой «a = 2» пишется через монады и пару вызовов функции, за которыми стоят еще штук двадцать вызовов функций внутри самого MTL. По сравнению с этим и раст, и паскаль, и ML кажется головоломками для детей дошкольного возраста.

а что, уже пятница ?

По моему у гцц лучше подлержка всякого ембеддед и «не популярных» архитектур.

И да, здоровая конкуренция - двигатель прогресса.

Именно по идеологическим. Такое вот «спо» с двойными стандартами )

Зачем вообще gcc тратит силы на g++, может лучше вообще забросить и отдать кресты в руки шланга?

Да зачем вообще что-то делать?

Тебе дают возможность выбора, в этом суть opensource.

Ну и эта, я пользуюсь gcc без шланга, полёт нормальный.

Нет уж, пусть развиваются оба и конкурируют друг с другом.

Если один из них перестанет развиваться, то всё превратится в типичный «совок» со стагнацией и без будущего. Напомню, что активная разработка GCC как раз была подстёгнута выходом Clang/LLVM, GCC до 4.8 развивался ну очень медленно.

Да, сегодня в сравнении с Clang/LLVM компилятор GCC выглядит монолитным комбайном, которому чужды принципы UNIX-Way. Компоненты Clang/LLVM являются переиспользуемыми, а не внутренней кухней, как в случае с GCC. Для создания собственных инструментов из Clang можно выдернуть парсер и на его основе реализовать подсветку кода, автодополнение и статический анализ, именно так и работают сегодня большинство IDE для C++, вместо написания собственных плохоработающих костылей. С GCC, к сожалению, такие финты работать не будут.

Остаётся только надеятся что со временем GCC станет более UNIX-Way’ным компилятором, который соблюдал бы принципы KISS так же хорошо, как это делает Clang/LLVM.

llvm - сила, ибо адекватная архитектура и лицензия. Поэтому его и выбирают для новых языков.

llvm - сила, ибо адекватная архитектура и лицензия.

Только на винде не работает без MSVS. Так что про архитектуру я сомневаюсь.

Что значит не работает? У меня работает.

Скачиваю https://github.com/llvm/llvm-project/releases/download/llvmorg-10.0.0/LLVM-10.0.0-win64.exe

Устанавливаю.

C:\Users\Monk>clang C:\Users\Monk\AppData\Local\Temp\superc-tmp15941744181594174418973.c
clang: warning: unable to find a Visual Studio installation; try running Clang from a developer command prompt [-Wmsvc-not-found]
clang: error: unable to execute command: program not executable
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Как заставить компилировать?

Поставить binutils.

А он разве существует под Windows (не в mingw/msys/wsl)? И clang пытается запустить link.exe, разве он есть в binutils?

gcc (ftp://ftp.equation.com/gcc/gcc-10.1.0-64.exe) на этом же компьютере успешно работает.

Насколько я понимаю, clang тянет только компилятор. Линкер и прочие добро внешнее.

С другой стороны мы говорим про винду, где и mingw инороднее некуда.

Насколько я понимаю, clang тянет только компилятор. Линкер и прочие добро внешнее.

Вот я и пишу, что gcc есть, который делает нормальные виндовые файлы (по крайней мере dll из Racket открывается), а clang обязательно хочет проприетарную компоненту.

С другой стороны мы говорим про винду, где и mingw инороднее некуда.

Именно. Я пробовал mingw’шные dll из виндовых программ открывать (Racket, Python). Ругаются, что не могут открыть файл (похоже, ld-config не находят).

И наоборот, виндовую dll внутрь mingw тоже не подключить (пытался GTK использовать).

Нормальные виндовые файлы - это те, которые зависят от vc redist. Ваш КО.

Возможно, что и зависят. По крайней мере с ними линкуются.

Ну начнём с того что неполноценен не g++, а тот кто без тэгов не может писать код. А так два свободных конкурирующих компилятора не уступающих друг другу - замечательная ситуация, как минимум ради этого каждый из них и нужен.

Нормальные виндовые файлы - это те, которые зависят от vc redist. Ваш КО

MSVC точно так же позволяет статически линковать бинарники.

Насколько я знаю - не позволяет. Поэтому все проги тагают с собой vcredist.

Лор-мышление: зачем что-то должно существовать, если есть что-то похожее/равное, чему я отдаю предпочтение.

Нормальные виндовые файлы - это те, которые зависят от vc redist

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

С чего это? Позволяет конечно.

Насколько я знаю - не позволяет. Поэтому все проги тагают с собой vcredist

Вот прям сейчас собрал проект статически — получил единственную зависимость от kernel32.dll.

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

Так в линуксе одновременно несколько версий libc даже не бесплатно сложно поставить