LINUX.ORG.RU

Разрешено использование C++ в GCC

 , , , , ,


0

1

Вчера в списке рассылки GCC появилось важное сообщение по поводу использования языка программирования C++ при разработке GCC (GNU Compiler Collection, а не сам компилятор языка C).

Марк Митчелл (Mark Mitchell), один из основных разработчиков GCC:

Я рад сообщить, что руководящий комитет GCC и FSF одобрили использование C++ в самом GCC. Конечно, нет никаких причин использовать возможности С++ только потому, что мы умеем это делать. Главная цель - предоставить пользователям более качественные компиляторы, а не кодовую базу на C++ для самих себя.

Перед тем, как мы действительно начнём использовать C++, мы должны определиться с набором правил, которыми нужно будет руководствоваться при использовании C++ для разработки GCC. Я считаю, что для начала мы должны минимизировать список разрешённых возможностей С++, чтобы не подвергать разработчиков GCC, не знакомых с C++, таким резким переменам в основном языке разработки компиляторов. Мы всегда сможем расширить использование С++ позднее, если появится такая необходимость.

На данный момент разработчики ограничиваются стандартом C++98 и использованием типа long long для 64-битных целых чисел. Использование множественного наследования, шаблонов (тех, которые не входят в стандартную библиотеку C++) и исключений, скорее всего, будет запрещено. Это мотивировано тем, что это будет сложно для программистов на C, а также тем, что сами программисты C++ могут с лёгкостью допустить ошибки в таких вещах.

Так как язык C++ достаточно обширен, то Марк Митчелл предложил составить список того, что разрешается использовать, а не того, что использовать нельзя. На данный момент необходимо составить некоторые информационные нормативы, а не очередной стандарт ISO.

Все желающие поучаствовать в разработке нормативов могут связаться с разработчиками GCC. На данный момент предполагается сделать это в виде странички в Wiki.

>>> Официальный анонс

★★★★

Проверено: JB ()

Ответ на: комментарий от JackyTreehorn

> В продукте фирмы, где я когда-то работал, исключения были отключены, и ничего, все работало. Между прочим, лидер на рынке учетных систем для медпрактик в Германии.

Да ну?

Допустим есть такой код:

try { rs = connection.makeQuery(sql); ... } catch (SQLException e) { log.error(«Shit happened», e); ... }

И отключены исключения.

Что произойдет, если makeQuery захочет кинуть SQLException? :-D

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

Боже.. Мне кажется, я понял. В контексте медпрактик Германии это значит, что если на секунду отвалилась сеть или кто-то по ошибке нажал не ту кнопку, то пациента отправят не к отоларингологу, а в крематорий. И даже прах не отдатут потом.

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

>>Мозиловцы видят недостатки важные для них.

Да - про это весь тред. С++ это недостаток который не могут реализовать нормально последние 27 лет.

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

Или видели когда-то, но сейчас уже поздно менять.

Ты русский язык понимаешь? Поменять можно хоть сейчас если покажешь что хоть одно из правил на заявленных компиляторах не выполняется. У мозилловцев как раз всяких бредовых предубеждений - нет.

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

Вот мне важны недостатки исключений.

лассическая задача:

Реализовать функцию f(x) = { 0 < x < 10 : x * x ; иначе недопустимый аргумент }

Вперед.

И зачем ты мне это привел? Этого в моей задаче нет. Это твоя задача и не приписывай мне ее. Моя задача - не твоя. Мне, допустим, надо интерпретатор другого языка, неподдерживающего исключения встроить. Причем он должен иметь доступ ко всей функциональности программы. И как мне избавиться от кидаемых библиотеками исключений? Обрабатывать при каждом вызове библиотечных функций? Как засоряет и усложняет код представляешь? А уж, что происходи в процессе частичного рефакторинга вообще можно не говорить.

Так дай мне инструмент отключения исключений в ява.

Ты думаешь, что все решают твои задачи?

И я не хочу их использовать в ява.

Инженерно. Научно. Мама я нехочу.

Какая разница как. Я вижу недостатки. И не хочу на них нарываться. Ты не видишь - твои проблемы.

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

>> Ну так ты ответь да или нет?

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

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

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

>> В продукте фирмы, где я когда-то работал, исключения были отключены, и ничего, все работало. Между прочим, лидер на рынке учетных систем для медпрактик в Германии.

Да ну?

Допустим есть такой код:

try { rs = connection.makeQuery(sql); ... } catch (SQLException e) { log.error(«Shit happened», e); ... }

И отключены исключения.

Что произойдет, если makeQuery захочет кинуть SQLException? :-D

Допустим в моей задаче его нет.

Что тогда. Я свою задачу знаю. Там библиотеки без исключений. Что тогда?

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

> И зачем ты мне это привел? Этого в моей задаче нет. бла бла бла

Ну не используй яву для этой задачи, и все. В чем проблема-то?
Яву не надо везде сувать, только там - где её ниша: ентерпрайз, сайты и пр.
А вот c++ никуда не надо сувать

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

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

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

>> И зачем ты мне это привел? Этого в моей задаче нет. бла бла бла

Ну не используй яву для этой задачи, и все. В чем проблема-то?

Яву не надо везде сувать, только там - где её ниша: ентерпрайз, сайты и пр.

Программа уже есть. Возникла необходимость встроить интерпретатор. Все переписывать? Работы очень много. Через чур. Легче от фонкциональности отказаться.

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

> Что тогда. Я свою задачу знаю. Там библиотеки без исключений. Что тогда?

Не надо увиливить от ответа. :-) Нем более, столь позорного для це-пе-пе.

Что до случая, когда ничто не бросает исключений, то для меня все кристально ясно: если компилятор при этом генерит тормозной код, то это его личные проблемы. :-) Ни в одной нормальной реализации Haskell или Common LISP с исключениями проблем нет. О проблемах с ним речь идет только в контексте «Великого и Могучего C++»

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

>Назови мне язык, несколько независимых реализаций которого двоично-совместимы.

JVM-но/.NETные устраивают.

И не надо толстеть самому - дело тут не в бинарной совместимости. А в том что одни исходники откомпилированные полностью разными компиляторами ведут себя по разному.

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

>> Допустим есть такой код

Нет такого кода.

Вы с головой дружите? Может у Вас и нет, но в природе подобного кода полно. Более того, исключения - весьма адекватный подход в библиотеках доступа к базам данных. Если не согласны - предложите API без исключений.

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

> Так же как и все остальные языки и стили программирования.

Все остальные языки обычно реализуют свои стандарты.

Только есть уже проблема больших проектов и унаследованного кода.


У тебя серьезные трудности с русским языком.

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


Я в свое время (это когда деревья были большими а GCC версии 2.95.x) доусрачки напортировался и наловился багов при переходах на третью ветку и дальше.

Этого в моей задаче нет.


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

Я вижу недостатки.


Ты несешь бред. Если ты его еще и видишь - обратись к специалисту.

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

Я дружу, а Вы вот читать не умеете. Я привел конкретный пример, остальное - Ваши выдумки.

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

> Хорошо работает

Обязательно. И синие слоны тоже рядом бегают.

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

>>Назови мне язык, несколько независимых реализаций которого двоично-совместимы.

JVM-но/.NETные устраивают.

Языки назови. Только не Java и C#, где были заранее стандартизованы аспекты реализации как VM, так и самих языков (Java и C#).

И не надо толстеть самому - дело тут не в бинарной совместимости.

А о чем вообще речь тогда? Потому что несовместимости между разными компиляторами были (даже я, не особо следивший за Явой, видел несовместимости между Jikes и компилятором Sun). И это при том, что стандарт Явы был специфицирован до появления первых независимых реализаций. И в Mono реализовывался не весь стандарт C#, и Jython был временами несовместим с Python.

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

> Ни в одной нормальной реализации Haskell или Common LISP с исключениями проблем нет.

Еще один толстяк. Каких проблем нет в Haskell и CL?

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

>Пример можно?

http://groups.google.com/group/comp.lang.c++.moderated/msg/79649e353976198d

И прочий микрософтовский SEH.

VC7.1 наплевать на throw specification.

А на WinCE их вообще нет....

На тему имплементации портабельных эксепшенов для плюсов даже книжки пишут список коих тут: http://en.wikipedia.org/wiki/Exception_handling

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

> И зачем ты мне это привел? Этого в моей задаче нет. Это твоя задача и не приписывай мне ее. Моя задача - не твоя. Мне, допустим, надо интерпретатор другого языка, неподдерживающего исключения встроить. Причем он должен иметь доступ ко всей функциональности программы. И как мне избавиться от кидаемых библиотеками исключений? Обрабатывать при каждом вызове библиотечных функций? Как засоряет и усложняет код представляешь? А уж, что происходи в процессе частичного рефакторинга вообще можно не говорить.

Ваша задача - идти в школу и учиться. Там объяснят, что из кала лепить не стоит, иначе получится modern art.

Только у Вас есть проблема с кидаемых библиотекой исключениями. :-) И только у Вас она выражается в усложнении и засорении кода. Догадываетесь почему? Правильно. «Сначала думай, потом пиши». В большинстве случаев корректная обработка исключений реализуется одним try-catch блоком в одном лишь месте программы. Очевидно, что на такой код потомственный копи-пэйстер не способен, так что...

Так дай мне инструмент отключения исключений в ява.

Только даун делает инструмент, отрезающий полезную функциональность. В Java исключения не мешают, это не С++. Поэтому их и не нужно отключать.

Если это - следствие нереального превосходства С++, то мне Вас жалко.

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

>> Этого в моей задаче нет.

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

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

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

>> Ни в одной нормальной реализации Haskell или Common LISP с исключениями проблем нет.

Еще один толстяк. Каких проблем нет в Haskell и CL?

Похоже Вы невменяемы, раз из моей фразы делаете вывод что я, дескать, троль. :-) И да, в Haskell и CL проблем меньше. Не согласны - докажите. :-)

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

>Языки назови.

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

Только не Java и C#, где были заранее стандартизованы аспекты реализации как VM, так и самих языков (Java и C#).


Что это еще за условие? А комитету отвечающему за стундарт С++ по рукам линейкой били за попітки стандартизировать исключения?

и Jython был временами несовместим с Python.


Правильно - не надо абсолютизировать. Но «временами не совместим пока не совместили» это не то же самое что «за 27 лет ни одной реализации спецификации». Ладно бы несовместимость между разными - так ни одной целой.

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

>> И зачем ты мне это привел? Этого в моей задаче нет. Это твоя задача и не приписывай мне ее. Моя задача - не твоя. Мне, допустим, надо интерпретатор другого языка, неподдерживающего исключения встроить. Причем он должен иметь доступ ко всей функциональности программы. И как мне избавиться от кидаемых библиотеками исключений? Обрабатывать при каждом вызове библиотечных функций? Как засоряет и усложняет код представляешь? А уж, что происходи в процессе частичного рефакторинга вообще можно не говорить.

Ваша задача - идти в школу и учиться. Там объяснят, что из кала лепить не стоит, иначе получится modern art.

Только у Вас есть проблема с кидаемых библиотекой исключениями. :-) И только у Вас она выражается в усложнении и засорении кода. Догадываетесь почему? Правильно. «Сначала думай, потом пиши». В большинстве случаев корректная обработка исключений реализуется одним try-catch блоком в одном лишь месте программы. Очевидно, что на такой код потомственный копи-пэйстер не способен, так что...

Я же тебе сказал, что нужно всю функциональность в апи интерпретатора вогнать. Теперь в каждой вгоняемой в апи интерпретатора функции лепится try catch. Так его еще и обработать надо....

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

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

У тебя нету функций возвращающих значения? Ни одной?



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

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

И вы, пишете просныти из if-the-else да switch после каждого вызова библиотечной функции, надеясь что не упустили ни одного случая? Вручную освобождая ресурсы? Надеясь, что все это будет работать?

Как говориться, «There is an ugly name for those, who do things the hard way».

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

>> Так дай мне инструмент отключения исключений в ява.

Только даун делает инструмент, отрезающий полезную функциональность. В Java исключения не мешают, это не С++. Поэтому их и не нужно отключать.

Если это - следствие нереального превосходства С++, то мне Вас жалко.

Только дауны верят в серебряные пули. Недостатки есть у всего. Если вы их не видите - это ваши проблемы. Но не мешайте тем кто их видит.

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

>Только дауны верят в серебряные пули.

Это ты про тех кто обяъявил плюсы языком всех времен и народов? ТАки да - дауны.

Но не мешайте тем кто их видит.



Изложи дорогой.

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

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

И вы, пишете просныти из if-the-else да switch после каждого вызова библиотечной функции, надеясь что не упустили ни одного случая? Вручную освобождая ресурсы? Надеясь, что все это будет работать?

Как говориться, «There is an ugly name for those, who do things the hard way».

Видищь ли. То что тебе не нравиться - это твоя проблема. Но компиляторы сейчас легко вылавливают упущенные случаи. :)

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

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

У тебя нету функций возвращающих значения? Ни одной?

Есть. Только у них или признак ошибки в параметре возвращается или она вообще без ошибок.

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

>Только у них или признак ошибки в параметре возвращается

я себе представляю во что превратится

x = 5 * f(a,b) / g(c)

и эти люди мешают мне ковырятся в носу видя недостатки исключений.

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

>> Только дауны верят в серебряные пули.

Это ты про тех кто обяъявил плюсы языком всех времен и народов? ТАки да - дауны.

Но не мешайте тем кто их видит.

Изложи дорогой.

Тебе бесполезно.

С твоей точки зрения - это не недостаток.

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

Если найдешь - недостатков нет. Не найдешь - вот он.

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

>> Только у них или признак ошибки в параметре возвращается

я себе представляю во что превратится

x = 5 * f(a,b) / g(c)

и эти люди мешают мне ковырятся в носу видя недостатки исключений.

Во что превратиться - это огромный недостаток для одних задач и сравнительно маленький для других. Вопрос в критериях.

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

> Только дауны верят в серебряные пули. Недостатки есть у всего. Если вы их не видите - это ваши проблемы. Но не мешайте тем кто их видит.

Перечислите недостатки исключений в Java, посмеемся вместе. Да еще и такие, что перевешивают недостатки написания ублюдочной ручной обработки кодов ошибок. %) Уже внимаю к мнению специалиста.

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

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

Я не знаю в какой ты пещере сидишь - но это делают IDE при чем _автоматически_ без проблем.

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

>> Перечислите недостатки исключений в Java, посмеемся вместе. Да еще и такие, что перевешивают недостатки написания ублюдочной ручной обработки кодов ошибок. %) Уже внимаю к мнению специалиста.

Повторюсь:

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

Если найдешь - недостатков нет. Не найдешь - вот он.

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

>сравнительно маленький для других.

Изложите задачи где код вида:

if (a < b) {
&error = 153;
return «всякий бред ибо ошибка»
}

небудет считаться кривым.

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

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

Я не знаю в какой ты пещере сидишь - но это делают IDE при чем _автоматически_ без проблем.

Покажи мне IDE умеющий все шаблоны рефакторинга.

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

>>сравнительно маленький для других.

Изложите задачи где код вида:

if (a < b) {
&error = 153;
return «всякий бред ибо ошибка»
}

небудет считаться кривым.

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

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

>> Языки назови.

Любые на этих платформах.

Не знаю языка «любой». Назови мне два сложных (уровня хотя бы Явы) языка на JVM/.NET, которые имеют беспроблемно совместимые независимо разработанные компиляторы.

Вод нело дошло до того что в груви уже можно указывать генерить совместимые со скалой сигнатуры.

У языков на VM есть определенные преимущества.

А комитету отвечающему за стундарт С++ по рукам линейкой били за попітки стандартизировать исключения?

Если ты не знал - их стандартизировали. У Си++ даже есть ABI (уже лет несколько назад). Но разница в том, что стандарт был принят _после_ появления нескольких несовместимых реализаций.

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

> Повторюсь:

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

Если найдешь - недостатков нет. Не найдешь - вот он.

Мощь. Насчет «от каждого к каждому» - не знаю. Сама формулировка бредова, так как предполагает, что список шаблоны широко известен и окончателен. Что, конечно говоря, чушь.

Но лично я ни разу проблем с рефакторингом не замечал, хотя пользовался им часто.

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

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

SEH тут вовсе не в тему, потому что к С++ напрямую не относится.
VC7.1 - древность. Современные компиляторы от МС вполне приличные, на мой взгляд.
Про СЕ ничего сказать не могу.

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

>> Повторюсь:

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

Если найдешь - недостатков нет. Не найдешь - вот он.

Мощь. Насчет «от каждого к каждому» - не знаю. Сама формулировка бредова, так как предполагает, что список шаблоны широко известен и окончателен. Что, конечно говоря, чушь.

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

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

Но лично я ни разу проблем с рефакторингом не замечал, хотя пользовался им часто.

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

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

То что не наблюдаете вы не значит, что не наблюдают остальные.

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

>Покажи мне IDE умеющий все шаблоны рефакторинга.

Поселе того как ты их все перечислишь, троль.

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

Я не вижу связи сложности рефакторинга с величиной проекта. Это относительно механистичный процесс при правильном подходе.

Значит не используете те шаблоны которые могут принести проблемы

Имя, сестра! (с) Надо заметить, что для С++ ваще нет тулов, которые бы поддерживали более-менее сложные варианты.

JackyTreehorn ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.