LINUX.ORG.RU

Будущее g++

 ,


0

2

Привет. Были разговоры, что шланг заменит ГЦЦ. Вот смотрю на g++, он активно пилится, оперативно внедряются всякие плюшки из новых стандартов, не похоже как-то на агонию. Может мне не повезло, но для крестов я так и не встретил ни одной нормальной tag системы, а кодить без неё удовольствие сомнительное. Шланг решил эту проблему, дав возможность комфортного, крестового кодописания. Вопрос - зачем нужен g++, если рядом должен быть установлен Шланг? Зачем вообще gcc тратит силы на g++, может лучше вообще забросить и отдать кресты в руки шланга? Просто интересно, ведь пилить компилятор - не самое простое занятие, да ещё и бессмысленное учитывая то, что g++ без шланга неполноценен. О чём они там в ГЦЦ думают? Может я просто не умею голый g++ (без шланга)?

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

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

Begemoth ★★★★★ ()
Ответ на: комментарий от Begemoth

Докладываю:

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

anonymous ()

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

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

xaizek ★★★★★ ()

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

RazrFalcon ★★★★★ ()

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

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

byko3y ()

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

pavlick ★★ ()
Ответ на: комментарий от pavlick

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

xDShot ★★★★★ ()
Ответ на: комментарий от RazrFalcon

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

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

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

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

fsb4000 ★★★ ()
Ответ на: комментарий от pavlick

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

xaizek ★★★★★ ()
Ответ на: комментарий от xaizek

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

SR_team ★★★★ ()
Ответ на: комментарий от pavlick

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

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

byko3y ()

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

menangen ★★★★★ ()
Ответ на: комментарий от Einstok_Fair

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

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

vertexua ★★★★☆ ()

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

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

SZT ★★★★ ()
Последнее исправление: SZT (всего исправлений: 1)

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

anonymous ()
Ответ на: комментарий от SZT

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

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

Siborgium ()

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

ox55ff ★★★ ()
Ответ на: комментарий от Siborgium

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

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

anonymous ()

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

anonymous ()
Ответ на: комментарий от byko3y

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

XMs ★★★★★ ()
Ответ на: комментарий от XMs

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

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

Siborgium ()
Последнее исправление: Siborgium (всего исправлений: 1)
Ответ на: комментарий от XMs

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

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

byko3y ()
Ответ на: комментарий от Siborgium

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

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

byko3y ()

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

anonymous ()

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

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

invy ★★★★★ ()
Последнее исправление: invy (всего исправлений: 1)
Ответ на: комментарий от xaizek

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

invy ★★★★★ ()

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

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

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

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

hobbit ★★★★★ ()

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

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

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

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

EXL ★★★★★ ()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от SZT

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

RazrFalcon ★★★★★ ()
Ответ на: комментарий от RazrFalcon

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

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

monk ★★★★★ ()
Ответ на: комментарий от RazrFalcon

Скачиваю 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)

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

monk ★★★★★ ()
Ответ на: комментарий от RazrFalcon

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

monk ★★★★★ ()
Ответ на: комментарий от monk

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

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

RazrFalcon ★★★★★ ()
Ответ на: комментарий от RazrFalcon

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

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

monk ★★★★★ ()
Ответ на: комментарий от RazrFalcon

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

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

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

monk ★★★★★ ()
Ответ на: комментарий от monk

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

RazrFalcon ★★★★★ ()
Ответ на: комментарий от RazrFalcon

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

monk ★★★★★ ()

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

slovazap ★★★★★ ()
Ответ на: комментарий от RazrFalcon

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

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

byko3y ()
Ответ на: комментарий от byko3y

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

RazrFalcon ★★★★★ ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от RazrFalcon

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

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

anonymous ()
Ответ на: комментарий от RazrFalcon

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

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

byko3y ()
Ответ на: комментарий от anonymous

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

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

monk ★★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)