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 ()
Последнее исправление: MuZHiK-2 (всего исправлений: 1)

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

>>Любые, где он выполняет свои задачи.

И этьи люди кричат что-то там про исключения.

И что? В чем проблема то?

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

Я слегка запутался, о чем речь, но у меня такое ощущение, что один про фому, а другой - про ерему.

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

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

Одного языка?

Пожалста: Java/C#. JRuby -> Ruby. Jython -> Python. куча реализаций JavaScript.

Мало?

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

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

Одного языка?

Пожалста: Java/C#. JRuby -> Ruby. Jython -> Python. куча реализаций JavaScript. VB# (.NET/Mono), JScript(.NET/Mono).

Не знаю как там статус .GNU возмоэжно реализаций даже больше.

Мало?

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

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

Одного языка?

Пожалста: Java/C#.

Mono C# долгое время реализовывал только подмножество C#, так что код, написанный на MS C#, был несовместим с Mono C#, ровно так же, как и у Си++. На этом спор о фатальных недостатках реализаций Си++ можно и закончить.

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

> В спагетти. Исключения позволяют этого избежать.

А зачем этого измегать, если задача решена и уровень сложности поддержки допустимый?

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

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

Да - стандарты. Ой - стандарты есть и на С++. Посмотри сколько этих jvm сделано. Пока активно все занимались (была много юниксав) - вполне было и у хулет-пакарда, бимеров, сантехников, и все стандартизировано и совместимо. И самое загадочное - оно и близко не жило 27 лет как С++. Так может в языке проблема?

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


Я ничуть не против. Скольлько лет назад это было?:)

Вот хорошая фраза:

Producing a reasonably standards-compliant C++ compiler has proven to be a difficult task for compiler vendors in general. In order to give compiler vendors greater freedom, the C++ standards committee decided not to dictate the implementation of name mangling, exception handling, and other implementation-specific features.

О чем мы спорим? Даже комитет по стандартизации С++ признает что изобрел монстра и форсировать вендоров реализовывать стандарт или стандартизировать имплементации - это как издевательство над пятилетними которые пытаются изучить атомную физику.

И ладно бы получили взамен что-то такое великое, стейт оф зе арт. Так нет - концептуально мрачно устаревший язык с кучей мрачных неоднозначностей, в большинстве случаев слишком низкоуровневый, все солидные фреймворки на котором могут заводить лозунг «на нашем фреймворке вам не надо мучится с этим чертовым с++».

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

>Современные компиляторы от МС вполне приличные, на мой взгляд.

Приличные. Годов через 10 глядишь хоть один реализующий стандарт появиться. Только что это покажет? Прошло уже 27 лет - ни одного совместимого со стандартом компилятора. Кагбэ намекает.

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

>Как только появляются исключения - этого гарантировать нельзя.

Это ты хвостом чувствуешь или PhD защитил по этому вопросу?

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

> Незачем. Но это уже другой вопрос - «не тронь говно...».

Да, но и еще. Где встать, что бы меньше воняло.

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

>И что? В чем проблема то?

Свои задачи выполняет и кирпичь подпирающий дверь в подьезде.

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

>> Как только появляются исключения - этого гарантировать нельзя.

Это ты хвостом чувствуешь или PhD защитил по этому вопросу?

Просто покажи методу учитывающие исключения.

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

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

>Mono C# долгое время реализовывал только подмножество C#

27 лет?:)

Сейчас mono C# реализцет стандарт С# 1.0/C# 2.0.

А ты что хотел - чтобы оно было «внезапно»? Понадобилось время.

C++ пишут уже 27 лет. При чем столько компаний которые вбухали в это дело столько бабла - мигель столько и представить не может. А где воз?




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

>Найдешь, троль?

А ты шаблоны проектирования от эквивалентных преобразований кода называемых рефакторинг не отличаешь, да?

И эти люди....

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

>> Найдешь, троль?

А ты шаблоны проектирования от эквивалентных преобразований кода называемых рефакторинг не отличаешь, да?

И эти люди....

Я и просил рефакторинг от шаблона к шаблону. Ты спросил список всех шаблонов или чего, троль?

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

>Ты так убежденно вещаешь, что я чуть было сам в это не поверил :-D

Голосуйте за меня на следующих выборах:)

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

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

Дай пример формализуется без исключений. А то до сих пор ты вообще путал шаблоны проектирования и эквивалентные преобразования кода.

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

>>> Как только появляются исключения - этого гарантировать нельзя.

Это ты хвостом чувствуешь или PhD защитил по этому вопросу?

Просто покажи методу учитывающие исключения.

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

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

>Я и просил рефакторинг от шаблона к шаблону.

Ты что совсем с дуба рухнул? Ну преобразуй мне васад к обсерверу.

Ты спросил список всех шаблонов или чего, троль?


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

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

>Стопроцентной реализации, может быть, и нет, но того, что есть, вполне достаточно.

Дык вопрос не в достаточности реализации чего-либо. От того что оно достаточно работает не проистекает что оно не уродливо само по себе.

Хорошего то там что?

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

> Стопроцентной реализации, может быть, и нет, но того, что есть, вполне достаточно.

ну можно и на brainfuck'e писать - тоже вполне достаточно, нет разве? Полный же язык, да и компиляторы, полностью реализующие спецификации есть.

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

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

Дай пример формализуется без исключений. А то до сих пор ты вообще путал шаблоны проектирования и эквивалентные преобразования кода.

Вообще я ни про какие эквивалентные преобразования не говорил. Это твоя фраза я говорил про эквивалентные шаблоны, то есть решающие одни и те же задачи.

Там есть: Замена параметра явными методами. http://www.rsdn.ru/res/book/prog/refactoring.xml

Покажи мне метод учитывающий исключения.

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

>Это экзистенциальный вопрос ;)

Могу подкинуть экзистенциальный ответ :) Стагнация в индустрии в результате чего все держиться на старых изобретениях: http://www.levenez.com/lang/lang.pdf

Посмотри как изменился характер графа с 1995 года. Только длинные линии - версии того чтобы было придумано до этого. А до 95 года что было? Изобретательство нового. А сейчас большинству народу лениво, корпорации не хотят тратить на это деньги, как-то говняненько работает? Ну и ладно. R&D глобально практически издох. Потмоу никто и не делает новый язык где низкоуровнемым будет только то что нужно, а не «на каждый стринг свой malloc».



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

Че-то я не понимаю, что ты хочешь доказать. Что этот рефакторинг не поддерживается автоматическими тулами?

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

Нашел в сети пример:

void setValue (String name, int value) {
   if (name.equals(«height»)) {
      _height = value;
      return;
   }
   if (name.equals(«width»)) {
      _width = value;
      return;
   }
   Assert.shouldNeverReachHere();
}

переводится в

void setHeight(int arg) {
   _height = arg;
}
void setWidth (int arg) {
   _width = arg;
}


И что тут сложного в поддержке исключений?
Вот вариант с исключениями:


void setValue (String name, int value) {
   if(value == -1) throw «Cannot accept -1 as a value»;
   if (name.equals(«height»)) {
      if(value == 13) thow «I do not feel lucky»;
      _height = value;
      return;
   }
   if (name.equals(«width»)) {
      _width = value;
      return;
   }
   Assert.shouldNeverReachHere();
}

переводится в

void setHeight(int arg) {
   if(value == -1) throw «Cannot accept -1 as a value»;
   if(value == 13) thow «I do not feel lucky»;
   _height = arg;
}
void setWidth (int arg) {
   if(value == -1) throw «Cannot accept -1 as a value»;
   _width = arg;
}

Такое хотели?

Проблема в том, что тулзы ваши это не могут? Меняйте тулзы.

Проблема в том, что вообще понадобился этот шизовый рефакторинг? Меняйте разработчиков.

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

>Вообще я ни про какие эквивалентные преобразования не говорил.

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

Там есть: Замена параметра явными методами. http://www.rsdn.ru/res/book/prog/refactoring.xml


А ты что разницы между тем что там перечисленно и тем что ты тыкал в дизайн петтернс не видишь? Или что?

Покажи мне метод учитывающий исключения.


На:
http://www.refactoring.com/catalog/replaceParameterWithExplicitMethods.html

Видишль там Assert? Это исключение вида IllegalArgument. Преобразовалось? Никто не умер?

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

> Н совсем то, но rак не забыть про это во всем коде?

Assert.shouldNeverReachHere();

Зависит от того, как выглядит вызов метода.

setValue(«height», 5) превратится в setHeight(5);

А вот конструкцию, где ключ заранее неизвестен, твой рефакторинг в люобом случае превратит в простыню if-else. И будет так:

if (name.equals(«height»)) { setHeight(value); } else if (name.equals(«width»)) { setWidth(value); } else { Assert.shouldNeverReachHere(); }

Ну и в чем проблема с исключениями?

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

>Современный С++ ваще-то не особо низкоуровневый.

Ты современным с++ назвал Qt чтоле?:)

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

>Оставшаяся после рефакторинга обработка исключений.

То что показал rtvd - семантически эквивалентный код. А телепатией вида «setValue никогда не вызывается ни с чем кроме height и width» тулза обладать не может - она только может посмотреть с чем вызывается. И если первый параметр во время анализа неконстантен - то преобразование соответствующее. И исключение тут не при чем.

А вот если нахреначить много ретурнов статусов - вот тут анализатор флова точно повесится.


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

>>Оставшаяся после рефакторинга обработка исключений.

То что показал rtvd - семантически эквивалентный код. А телепатией вида «setValue никогда не вызывается ни с чем кроме height и width» тулза обладать не может - она только может посмотреть с чем вызывается. И если первый параметр во время анализа неконстантен - то преобразование соответствующее. И исключение тут не при чем.

А вот если нахреначить много ретурнов статусов - вот тут анализатор флова точно повесится.

Тут да. Но вместо асерта запихнуть исключение. Как после рефакторинга не забыть убрать их обработку? Учитывая, что такое же исключение может кидать другой метод.

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

> Оставшаяся после рефакторинга обработка исключений.

К стати хотелось бы увидеть вот этот пример со статусами и результат рефакторинга этих статусов.

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

> Оставшаяся после рефакторинга обработка исключений.

Жаль что аноним. :-) Профессионалов следует знать в лицо.

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

> К стати хотелось бы увидеть вот этот пример со статусами и результат рефакторинга этих статусов.

Кстати да. Дорогой аноном, будьте добры продемонстрировать нам пример. :) Поучимся у Вас уму-разуму.

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

>Но вместо асерта запихнуть исключение.

Ассерт - это исключение и есть.

Как после рефакторинга не забыть убрать их обработку?


Точно так же как ты будешь убировать обработку статусов на каждый чих.

Уж не говоря о том что «обрабатывать» ассерты - за это надо с работы выгонять (кроме нескольких специфичных случаев).

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

>> К стати хотелось бы увидеть вот этот пример со статусами и результат рефакторинга этих статусов.

Кстати да. Дорогой аноном, будьте добры продемонстрировать нам пример. :) Поучимся у Вас уму-разуму.

Как со статусами не знаю. Но с кодом возврата все просто.

int setValue(...,...) { return UNKNOWN_VALUE; }

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

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