План (http://gcc.gnu.org/wiki/cxx-conversion) частичного перевода набора компиляторов GCC с языка Си на Си++ начинает сбываться (http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html) - осуществлено (http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2b15d2ba7eb3a25...) слияние веток cxx-conversion (http://gcc.gnu.org/wiki/cxx-conversion) и trunk. Начиная с GCC 4.8 для сборки GCC может быть использован только компилятор С++. Целью перехода к использованию языка C++ для разработки GCC является чистка и переработка отдельных внутренних компонентов проекта, в которых наблюдаются проблемы с небезопасной типизацией. Такие компоненты постепенно будут переписаны с использованием классов и шаблонов C++. Полная переработка GCC на C++ не входит в планы разработчиков.URL: http://developers.slashdot.org/story/12/08/15/1338212/gcc-sw...
Новость: http://www.opennet.me/opennews/art.shtml?num=34588
а g++ будут собирать при помощи gcc?
Думаю, что нет. Скорее всего это будет обыкновенный bootstrap: для g++ нужен будет g++. Но нужно будет отдельно проверять тем, кому это в самом деле интересно.
>обыкновенный bootstrap:Спасибо! Он не знал.Ж)
А ведь два года прошло с момента "разрешения" использования C++ в GCC... Я надеялся что все забудут :)
Надо было сразу шлангом
Давно пора. Использование C++ повлияет и на архитектуру проекта. Она станет более стройной. Разделение на низкоуровневый слой и стройную высокоуровневую архитектуру поможет ускорить развитие проекта.
... или превратить проект в кашу.
Он уже каша. Если вы про код. Я вот про код.
Это зависит от разработчиков, не от ЯП. Можно и на PHP писать прекрасный код. А на великолепном Ruby напортачить так, что и не разберёшься потом что и где. Качество кода никак не коррелирует с ЯП.
набыдлокодить можно на любом ЯП
> ... поможет ускорить развитие проекта.и замедлить его сборку
Чушь. Использование одного языка вместо другого никак не сделает архитектуру "более стройной".
Не сделает, но позволит сделать.
Это относится почти к любому ЯП.
>Это относится почти к любому ЯП.fixed: Это относится почти к любому ЯООП.
Ошибаетесь. Сам ЯП никак не влияет на качество кода, и качество архитектуры проекта. Но люди использующие к месту ООП, проектирую более стройные и удобные, легкоподдерживаемые интерфейсы. Использование некоторых возможностей C++ позволит отделить те части кода, которые должны быть сильно оптимизированны от кода, уровень которого может(и должен) быть выше. Посмотрите на LLVM. Создать новый компилятор с использование LLVM намного легче, чем с нуля. Низкоуровневые оптимизации вообще не проблема создателя компилятора. Их решают разработчики LLVM. А создателю компилятора для нового ЯП достаточно создать копилятор в LLVM-JIT. Для кодогенерации используются библиотеки проекта. По сути дела LLVM - это просто находка для создателей различных компиляторов. GCC может стать ещё лучше, если его грамотно спроектировать.
> Но люди использующие к месту ООП, проектирую более стройные и удобные, легкоподдерживаемые интерфейсы.Сомневаюсь. Добавьте метод в базовый класс и ваш "стройный и удобный, легкоподдерживаемый интерфейс" летит ко всем чертям - ВСЕ библиотеки, использующие этот класс, надо перекомпилировать, иначе теряется бинарная совместимость.
это проблема C++ ABI у gcc ;-)
у некоторых этой проблемы нету.
> это проблема C++ ABI у gcc ;-)
> у некоторых этой проблемы нету.как страшно жить
> у некоторых этой проблемы нету.Это у кого же? Назовите мне компилятор C++, который позволит изменить базовый класс без необходимости перекомпиляции всего наследующего кода? :)
100500 раз просим!
Но сдаётся мне что кто просто зря побеспокоил водную поверхность ...
Мне, как "крестовику", добавление методов в базовый класс, используемый многими библиотеками, представляется куда более страшным и опасным делом, чем перекомпиляция этих библиотек.
Особенно если этот базовый класс предоставляет именно интерфейс. Зачем в интерфейсе, уже используемом многими библиотеками, что-то менять? Нужен новый функционал - применяйте наследование. Однако, если действительно меняется интерфейс, странно не затронуть тех, кто им пользуется.
> Зачем в интерфейсе, уже используемом многими библиотеками, что-то менять?Добро пожаловать в реальный мир! :)
Видимо, вы так делаете каждый день.
Да, каждое утро, после пробуждения :)
Нормальные люди добавляют виртуальные методы в конец списка и не имеют проблем — как и научено в манах по поддержанию бинарной совместимости. Гуглить маны KDE и Qt.
Те есть тот же гцц подойдёт? Ты редкостный петросян! :)
Подумай ещё раз.
>>> компоненты постепенно будут переписаны с использованием классов и шаблонов C++.Ух ты теперь gcc будет себя компилировать неделю ???
>будет себя компилировать неделю ???Интел Корп. [и дилеры] будет рад продать Вам новейших надцатиядрёных утюгов для решения Вашего затруднения.
clang решит его затруднения. а надцатиядерные утюги интел продаст дистростоителям вашего дистра.
> Ух ты теперь gcc будет себя компилировать неделю ???либра собирается за 40 минут, а она намного объемнее
Кстати, подобные работы ведутся сейчас и в gdb...
этим клоунам не помещало бы для начала уйти с cvs
они давно уже на svn
офигеть какой проресс!</sarcasm> :-D :-D :-D
зачем же ты врёшь, они сидят на cvs
вот прув http://sources.redhat.com/gdb/current/и патчи они принимают только относительно свего cvs
Из-за чего драма?http://www.gnu.org/software/gdb/current/
> git clone git://sourceware.org/git/gdb.git
Интервал синхронизации мешает? Так ваше письмо дольше идти будет.
Ну все прындец, станет еще хуже
А почему в каментах к новости о GCC нет ни одного упоминания о Clang?
Непорядок!
> А почему в каментах к новости о GCC нет ни одного упоминания
> о Clang?
> Непорядок!Отключите криокамеру, уважаемый.
>> Сообщение от анон on 16-Авг-12, 02:27
>> Надо было сразу шлангом
когда-то CLang за это ругали, теперь GCC догоняет
> А почему в каментах к новости о GCC нет ни одного упоминания
> о Clang?
> Непорядок!уже есть. я добавил :)
Адептов Си всё меньше, это испытание нашей веры. Нужно всё это вынести, и там за горами всё станет как прежде...
<вброс>Да ладно! Религиозный фанатизм, по-моему, как раз характерен для адептов С++. Потому, что они "мыслят классами", а не головой, и думают, что если используется ООП, то архитектура автоматически становится "стройной". Ну, а мы, наСИльники, понимаем, что Си - плохой язык, но лучше пока не придумали ;))</вброс>
Ок, продолжим :-)Вы, наСИльники, никак не можете понять, что плюсы ни одного инструмента не отбирают, только добавляют. А разработчики gcc явно имеют достаточную квалификацию чтобы их грамотно использовать.
Ну и "проблемы с небезопасной типизацией" наСИльников не волнуют ;-)
> плюсы ни одного инструмента не отбирают, только добавляютВот это-то и плохо. "Сущности не следует умножать без необходимости". http://yosefk.com/c++fqa/images/cat.png
> Ну и "проблемы с небезопасной типизацией" наСИльников не волнуют ;-)
Решая "проблему небезопасной типизации", С++ создаёт другую проблему: геморрой при преобразовании типов.
Очевидно, разработчиков больше волнуют проблемы небезопасной типизации, чем легкость преобразования типов.
Полагаю, они учитывают правило "код читается чаще, чем пишется" и предпочитают доверить компьютеру те проверки, которые он может выполнять автоматически. Даже если это чуть уменьшит продуктивность программистов.
Ну, насколько я понимаю, "небезопасная типизация" их вообще не волновала. Они перешли на С++, в основном, ради шаблонов.
Оглашался список того, ради чего они перешли. Там и STL вместо велосипедов, и smart pointers вместо сборщика мусора, и inline вместо макросов, и другие приятные вещи. Безопасная типизация, как минимум, не ухудшит качество самого кода, при этом фактически заставит сделать его ревизию. Почему нет?
Да на здоровье! С самого начала почему на С++ не стали писать? И почему полная переработка на C++ не входит в планы разработчиков? Не так, там наверное, всё вкусно... :)
> С самого начала почему на С++ не стали писать?Посмотрите историю GCC и C++ хотя бы в Википедии.
> И почему полная переработка на C++ не входит в планы разработчиков?
Потому что они не маются дурью со скуки, а работают. Перерабатывают те части, которые развиваются, и те, которые тяжелы в сопровождении. Зачем впустую переписывать то, что уже отлажено, работает и не доставляет проблем?
> Посмотрите историю GCC и C++ хотя бы в Википедии.Угу. И вы тоже. И увидите, что Столлман начал писать его вообще на Паскале - ещё одном языке с "безопасной типизацией", - но почему-то потом его переписали на "небезопасный" Си. А прелести С++, почему-то, до сего дня никого не прельщали.
> Зачем впустую переписывать то, что уже отлажено, работает и не доставляет проблем?
Действительно! И какая разница, что там не используется STL, smart pointers, и __inline вместо inline?
> Угу. И вы тоже. И увидите, что... ответ на ваш вопрос "почему не написали на С++ с самого начала?" тривиален. С++ тогда было год от роду, и стандартов на него, в отличие от С, не было.
> не используется STL
Не использоВАЛСЯ. А был, например, велосипедный VEC, который сейчас заменяют на std::vector. Познакомьтесь поближе с материалом, о котором рассуждаете.
> С++ тогда было год от роду,Не совсем так. "Си с классами" появился в 1979 г., в С++ его переименовали в 1983-м, а первая версия GCC появилась только в 1987-м. Так что, С++ тогда было, как минимум, 4 года.
> и стандартов на него, в отличие от С, не было.
А причём здесь стандарты С++? Столлман вообще начал писать GCC на собственной, ни с чем не совместимой версии Паскаля, и отсутствие стандартов на неё ему никак не мешало :)
> Не использоВАЛСЯ.
В оставшихся модулях, написанных на Си, которые работают и не доставляют проблем, не испольЗУЕТСЯ. Читайте внимательнее :)
> Так что, С++ тогда было, как минимум, 4 года.И до первого стандарта С++ оставалось еще два года. Между прочим, "когда вышла первая версия GCC" - это время, когда он уже был написан. Начали его писать несколько раньше.
> А причём здесь стандарты С++?
При том, что тогда причин предпочесть именно этот язык было не больше, чем сейчас - в пользу D или Vala.
> В оставшихся модулях, написанных на Си, которые работают и не доставляют проблем,
> не испольЗУЕТСЯ. Читайте внимательнее :)Читайте внимательно и вы: там используются велосипеды, код которых будет изменен, а "оставшиеся модули" теперь будут обращаться уже не к велосипедам, а к оберткам над STL-классами. Это еще не повод переписывать эти модули - достаточно перекомпилировать и убедиться, что они проходят тесты.
>> А причём здесь стандарты С++?
> При том, что тогда причин предпочесть именно этот язык было не больше, чем сейчас - в пользу D или Vala.Я так и не понял, при чём здесь стандарты... Главный причина выбора ЯП для решения какой-либо задачи - его удобство для решения этой задачи, а не наличие/отсутствие стандартов на него.
Стандарты здесь ни при чем. Но всерьез впрягаться писать что-либо сложное на языке с неопределенным будущим - глупость. Тем более, что компиляторы пишут отнюдь не "на один запуск". Приходится задумываться о долгосрочной поддержке и выбирать решения из мэйнстрима, просто чтобы со временем не огрести головной боли.
Э нет, простите. Тут вы в корне неправы.Инфраструктура (наличие библиотек, рынка труда, инфы, проверенных паттернов и примеров, перспектив развития, стандартов) как правило не менее важна чем пригодность самого языка в его текущем виде. Иначе, например, на Хаскеле или D писало бы *гораздо* больше народу.
> Решая "проблему небезопасной типизации", С++ создаёт другую проблему: геморрой при преобразовании
> типов.Именно в этом проблема. А жаль, мне хочется шаблонов немножко... Но уш лучше простота в преобразовании.
Хотя в последнем си стандарте... Но я ещё не дожил чтоб это попробовать, минГв се дела...
Или уже реализовано там?
на самом деле это неправда, маразматичный страуструп насильственно насаживает модель ооп в плюсах, в отличие от си плюсы не являются мультипарадигменным яп. Вот пример мармазма этого олегофренаhttp://www.stroustrup.com/bs_faq2.html#finally
Why doesn't C++ provide a "finally" construct?
Because C++ supports an alternative that is almost always better: The "resource acquisition is initialization" technique (TC++PL3 section 14.4). The basic idea is to represent a resource by a local object, so that the local object's destructor will release the resource. That way, the programmer cannot forget to release the resource.
и что тут такого «маразматичного»? у си, например, нет *никакого* механизма для этого — ни автоматических объектов с cleanup, ни finally.
Согласен. Маразм. Если программист должен явно резервировать ресурс, то он же должен явно его и освобождать. Это логично.> That way, the programmer cannot forget to release the resource.
Ну, да, программист "не может забыть", потому что он И НЕ ПОМНИТ об этом - за него это делает неявный вызов деструктора! И это - плохая практика, т.к. ПРИУЧАЕТ программиста не думать об освобождении ресурсов. Ну и вообще в духе С++: никогда толком не знаешь, в какой момент компилятор решит неявно вызвать конструктор\деструктор...
> Ну и вообще в духе С++: никогда толком не знаешь, в какой момент компилятор решит неявно вызвать конструктор\деструктор...Вы с PHP или Java не перепутали? Я почему-то не страдаю такими вопросами, давно и продуктивно используя С++. Всегда понятно, где может кончиться время жизни объекта и будет вызван деструктор.
> Ну и вообще в духе С++: никогда толком не знаешь,
> в какой момент компилятор решит неявно вызвать конструктор\деструктор…а ты язык-то учить не пробовал? сильно помогает узнать, когда же гадский компилятор…
Судя по тому, что конструктор и деструктор должен вызывать компилятор, это был какой-то другой язык...
тоже верно…
тут вся проблема не в этом. А в том, что место небольшогшо куска кода с try/finall нужно городить целый грёбанный класс, на пустом месте. Или другими сдовами, этот ебанутый старпёр вынуждает пользоваться только ООП парадигмой, либо лепить костыли в C стиле.
Если у вас классы создаются "на пустом месте", без какого-либо оригинального кода - просто используйте ОДИН шаблон для таких классов. Не надо костылей.
> Полная переработка GCC на C++ не входит в планы разработчиков.а жаль!!
Они не осилят переработать ТАКОЙ объём кода
пропал калабуховский дом. будем иметь ещё более страшного монстрика: теперь со вкусом C++.радует только одно: обычно ребята очень неспешно реализуют задумки. так что немного ещё поживём.
C говно уже только потому что у него нет деструкторов и шаблонов. С++11 с лямбда функциями, автовыводом типов и списками инициализации - вкусняшка. Адепты С(включая кстати самого Линуса) катятся куда подальше. Разработчикам GCC - респект, хотя одна только смена языка не поможет догнать clang по качеству кода.
"Тот, кто не горбатый, страшно некрасив" (с) Верблюд
Значит ли это что gcc теперь станет еще медленнее?
gcc станет мудрее )))
