| |
| 2.2, Да (?), 00:38, 16/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
Думаю, что нет. Скорее всего это будет обыкновенный bootstrap: для g++ нужен будет g++. Но нужно будет отдельно проверять тем, кому это в самом деле интересно.
| | |
|
| 1.3, BratSinot (?), 01:57, 16/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А ведь два года прошло с момента "разрешения" использования C++ в GCC... Я надеялся что все забудут :)
| | |
| 1.5, lucentcode (ok), 03:46, 16/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– |
 Давно пора. Использование C++ повлияет и на архитектуру проекта. Она станет более стройной. Разделение на низкоуровневый слой и стройную высокоуровневую архитектуру поможет ускорить развитие проекта.
| | |
| |
| |
| 3.39, lucentcode (ok), 14:58, 16/08/2012 [^] [^^] [^^^] [ответить]
| +3 +/– |
Это зависит от разработчиков, не от ЯП. Можно и на PHP писать прекрасный код. А на великолепном Ruby напортачить так, что и не разберёшься потом что и где. Качество кода никак не коррелирует с ЯП.
| | |
|
| 2.24, dq0s4y71 (??), 12:35, 16/08/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
Чушь. Использование одного языка вместо другого никак не сделает архитектуру "более стройной".
| | |
| |
| |
| 4.43, dq0s4y71 (??), 15:25, 16/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Но люди использующие к месту ООП, проектирую более стройные и удобные, легкоподдерживаемые интерфейсы.
Сомневаюсь. Добавьте метод в базовый класс и ваш "стройный и удобный, легкоподдерживаемый интерфейс" летит ко всем чертям - ВСЕ библиотеки, использующие этот класс, надо перекомпилировать, иначе теряется бинарная совместимость.
| | |
| |
| |
| 6.47, kurokaze (ok), 15:36, 16/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > это проблема C++ ABI у gcc ;-)
> у некоторых этой проблемы нету.
как страшно жить
| | |
| 6.49, dq0s4y71 (??), 15:37, 16/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> у некоторых этой проблемы нету.
Это у кого же? Назовите мне компилятор C++, который позволит изменить базовый класс без необходимости перекомпиляции всего наследующего кода? :)
| | |
| |
| 7.57, Ы (?), 17:39, 16/08/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
100500 раз просим!
Но сдаётся мне что кто просто зря побеспокоил водную поверхность ...
| | |
|
|
| 5.50, тоже Аноним (ok), 16:13, 16/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
 Мне, как "крестовику", добавление методов в базовый класс, используемый многими библиотеками, представляется куда более страшным и опасным делом, чем перекомпиляция этих библиотек.
Особенно если этот базовый класс предоставляет именно интерфейс. Зачем в интерфейсе, уже используемом многими библиотеками, что-то менять? Нужен новый функционал - применяйте наследование. Однако, если действительно меняется интерфейс, странно не затронуть тех, кто им пользуется.
| | |
| |
| 6.59, dq0s4y71 (??), 18:02, 16/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Зачем в интерфейсе, уже используемом многими библиотеками, что-то менять?
Добро пожаловать в реальный мир! :)
| | |
|
| 5.56, Аноним (-), 17:25, 16/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
Нормальные люди добавляют виртуальные методы в конец списка и не имеют проблем — как и научено в манах по поддержанию бинарной совместимости. Гуглить маны KDE и Qt.
| | |
| |
| 6.58, Ы (?), 17:41, 16/08/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
Те есть тот же гцц подойдёт? Ты редкостный петросян! :)
| | |
|
|
|
|
|
| 1.11, Аноним (-), 10:03, 16/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
>>> компоненты постепенно будут переписаны с использованием классов и шаблонов C++.
Ух ты теперь gcc будет себя компилировать неделю ???
| | |
| |
| 2.18, Andrey Mitrofanov (?), 11:15, 16/08/2012 [^] [^^] [^^^] [ответить]
| +2 +/– | |
>будет себя компилировать неделю ???
Интел Корп. [и дилеры] будет рад продать Вам новейших надцатиядрёных утюгов для решения Вашего затруднения.
| | |
| |
| 3.80, Клыкастый2 (?), 10:08, 17/08/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
clang решит его затруднения. а надцатиядерные утюги интел продаст дистростоителям вашего дистра.
| | |
|
| 2.48, kurokaze (ok), 15:37, 16/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Ух ты теперь gcc будет себя компилировать неделю ???
либра собирается за 40 минут, а она намного объемнее
| | |
|
| 1.22, 1q2w3e (?), 11:50, 16/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А почему в каментах к новости о GCC нет ни одного упоминания о Clang?
Непорядок!
| | |
| |
| 2.23, Альтернимус (?), 12:33, 16/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
> А почему в каментах к новости о GCC нет ни одного упоминания
> о Clang?
> Непорядок!
Отключите криокамеру, уважаемый.
>> Сообщение от анон on 16-Авг-12, 02:27
>> Надо было сразу шлангом | | |
| 2.81, Клыкастый2 (?), 10:09, 17/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
> А почему в каментах к новости о GCC нет ни одного упоминания
> о Clang?
> Непорядок!
уже есть. я добавил :)
| | |
|
| 1.25, Синоним (?), 13:01, 16/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Адептов Си всё меньше, это испытание нашей веры. Нужно всё это вынести, и там за горами всё станет как прежде...
| | |
| |
| 2.26, dq0s4y71 (??), 13:20, 16/08/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
<вброс>Да ладно! Религиозный фанатизм, по-моему, как раз характерен для адептов С++. Потому, что они "мыслят классами", а не головой, и думают, что если используется ООП, то архитектура автоматически становится "стройной". Ну, а мы, наСИльники, понимаем, что Си - плохой язык, но лучше пока не придумали ;))</вброс>
| | |
| |
| 3.28, Crazy Alex (ok), 14:03, 16/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
 Ок, продолжим :-)
Вы, наСИльники, никак не можете понять, что плюсы ни одного инструмента не отбирают, только добавляют. А разработчики gcc явно имеют достаточную квалификацию чтобы их грамотно использовать.
Ну и "проблемы с небезопасной типизацией" наСИльников не волнуют ;-)
| | |
| |
| 4.32, dq0s4y71 (??), 14:17, 16/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> плюсы ни одного инструмента не отбирают, только добавляют
Вот это-то и плохо. "Сущности не следует умножать без необходимости". http://yosefk.com/c++fqa/images/cat.png
> Ну и "проблемы с небезопасной типизацией" наСИльников не волнуют ;-)
Решая "проблему небезопасной типизации", С++ создаёт другую проблему: геморрой при преобразовании типов.
| | |
| |
| 5.34, тоже Аноним (ok), 14:29, 16/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
Очевидно, разработчиков больше волнуют проблемы небезопасной типизации, чем легкость преобразования типов.
Полагаю, они учитывают правило "код читается чаще, чем пишется" и предпочитают доверить компьютеру те проверки, которые он может выполнять автоматически. Даже если это чуть уменьшит продуктивность программистов.
| | |
| |
| 6.35, dq0s4y71 (??), 14:44, 16/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
Ну, насколько я понимаю, "небезопасная типизация" их вообще не волновала. Они перешли на С++, в основном, ради шаблонов.
| | |
| |
| 7.38, тоже Аноним (ok), 14:51, 16/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
Оглашался список того, ради чего они перешли. Там и STL вместо велосипедов, и smart pointers вместо сборщика мусора, и inline вместо макросов, и другие приятные вещи. Безопасная типизация, как минимум, не ухудшит качество самого кода, при этом фактически заставит сделать его ревизию. Почему нет?
| | |
|
|
| 5.53, Синоним (?), 16:58, 16/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Решая "проблему небезопасной типизации", С++ создаёт другую проблему: геморрой при преобразовании
> типов.
Именно в этом проблема. А жаль, мне хочется шаблонов немножко... Но уш лучше простота в преобразовании.
| | |
| |
| 6.54, Синоним (?), 17:07, 16/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
Хотя в последнем си стандарте... Но я ещё не дожил чтоб это попробовать, минГв се дела...
Или уже реализовано там?
| | |
|
|
| 4.70, Аноним (-), 23:31, 16/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
на самом деле это неправда, маразматичный страуструп насильственно насаживает модель ооп в плюсах, в отличие от си плюсы не являются мультипарадигменным яп. Вот пример мармазма этого олегофрена
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.
| | |
| |
| 5.71, arisu (ok), 23:37, 16/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
 и что тут такого «маразматичного»? у си, например, нет *никакого* механизма для этого — ни автоматических объектов с cleanup, ни finally.
| | |
| 5.82, dq0s4y71 (??), 13:54, 17/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
Согласен. Маразм. Если программист должен явно резервировать ресурс, то он же должен явно его и освобождать. Это логично.
> That way, the programmer cannot forget to release the resource.
Ну, да, программист "не может забыть", потому что он И НЕ ПОМНИТ об этом - за него это делает неявный вызов деструктора! И это - плохая практика, т.к. ПРИУЧАЕТ программиста не думать об освобождении ресурсов. Ну и вообще в духе С++: никогда толком не знаешь, в какой момент компилятор решит неявно вызвать конструктор\деструктор...
| | |
| |
| 6.84, тоже Аноним (ok), 14:42, 17/08/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Ну и вообще в духе С++: никогда толком не знаешь, в какой момент компилятор решит неявно вызвать конструктор\деструктор...
Вы с PHP или Java не перепутали? Я почему-то не страдаю такими вопросами, давно и продуктивно используя С++. Всегда понятно, где может кончиться время жизни объекта и будет вызван деструктор.
| | |
| 6.87, arisu (ok), 21:16, 17/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Ну и вообще в духе С++: никогда толком не знаешь,
> в какой момент компилятор решит неявно вызвать конструктор\деструктор…
а ты язык-то учить не пробовал? сильно помогает узнать, когда же гадский компилятор…
| | |
| |
| 7.88, тоже Аноним (ok), 22:47, 17/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
Судя по тому, что конструктор и деструктор должен вызывать компилятор, это был какой-то другой язык...
| | |
|
| 6.93, Аноним (-), 23:41, 17/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
тут вся проблема не в этом. А в том, что место небольшогшо куска кода с try/finall нужно городить целый грёбанный класс, на пустом месте. Или другими сдовами, этот ебанутый старпёр вынуждает пользоваться только ООП парадигмой, либо лепить костыли в C стиле.
| | |
| |
| 7.94, тоже Аноним (ok), 11:52, 18/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
Если у вас классы создаются "на пустом месте", без какого-либо оригинального кода - просто используйте ОДИН шаблон для таких классов. Не надо костылей.
| | |
|
|
|
|
|
|
| 1.31, Аноним (-), 14:10, 16/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
> Полная переработка GCC на C++ не входит в планы разработчиков.
а жаль!!
| | |
| 1.66, arisu (ok), 20:44, 16/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
пропал калабуховский дом. будем иметь ещё более страшного монстрика: теперь со вкусом C++.
радует только одно: обычно ребята очень неспешно реализуют задумки. так что немного ещё поживём.
| | |
| 1.69, Толстый (ok), 23:16, 16/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– |
 C говно уже только потому что у него нет деструкторов и шаблонов. С++11 с лямбда функциями, автовыводом типов и списками инициализации - вкусняшка. Адепты С(включая кстати самого Линуса) катятся куда подальше. Разработчикам GCC - респект, хотя одна только смена языка не поможет догнать clang по качеству кода.
| | |
|
