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)

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

ну да, через костыли можно все сделать, не спорю

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

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

Пример непонятен.

Будьте добры продемонтрировать код до рефакторинга и после. В том числе то, как изменятся вызовы setValue.

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

>Дальше при компиляции при замене этого вызова новыми тут же проверяется используетя ли возвращаемое значение.

О май год.

Используется - в каждом месте где вызывалось - стоит проверка. Нука зарефактори.


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

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

Пример непонятен.

Будьте добры продемонтрировать код до рефакторинга и после. В том числе то, как изменятся вызовы setValue.

Забванов. :)

Все то же самое:

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

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

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

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

С исключениями:

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

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

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

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

Вообще, исключения хороши, сокращением работы в текущий момент. Но это отложенная работа. В процессе разработки отложенная работа имеет свойство накапливаться приводя усложнению разработки. Последнее не мои мысли. Просто вычитал и осознал.

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

>> Дальше при компиляции при замене этого вызова новыми тут же проверяется используетя ли возвращаемое значение.

О май год.

Используется - в каждом месте где вызывалось - стоит проверка. Нука зарефактори.

Так в ручную и убираешь. С исключениями хрен найдешь где убирать.

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

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

27 лет?:)

Первый _стандарт_ Си++ - это 1997 год, какие еще 27 лет? %)

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

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

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

Не знаю. А если учесть, что в .NET мигель занимался повторной реализацией платформы, в которую M$ вбухал миллиарды... думаю, Си++ такие деньги просто не снились.

А где воз?

Сколько компиляторов Си++ на свете? А сколько C#? Вот там и воз.

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

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

Сила. А теперь вопрос к автору кода: что вернет эта функция, если первый аргумент - «height». :)

Далее.. Примера того, как изменится код вывода не было приведено. Вместо этого был процитирован мой же код. :)

Далее.. То, что в плюсах хреново с статическим анализом кода в случае исключений, не значит что в Java так же плохо. Особенно, когда речь идет о checked exceptions, которыми и пользуются люди.

В процессе разработки отложенная работа имеет свойство накапливаться приводя усложнению разработки.

Абсолютно точно. Особенно если «отложенная работа» это работа мозга.

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

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

А куда делся return UNKNOWN_VALUE? Или у тебя рефакторинг тул - это китаец который знает что этот код не понадобитиься? Или у IDE прямой контакт с господом?

setValue сразу проверяется обрабатывается ли значение кода ошибки.


Значение ошибки обрабатывается.

было if (setValue(«width», 100) != UNKNOWN_VALUE) {....}

стало...?

Нука напиши?

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


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

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

PS: Ты вот это компилить то пробовал:

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

Попробуй. Увидишь какую чушь написал.





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

>Так в ручную и убираешь.

Правда! Ты вообще семантически эквивалентный нормальный код без исключенйи не сгенеришь.

Была проверка на статус код. У методов типа setWidth return type - void. Ты вообще пока не показал как это семантически эквивалентно преобразовать.

Был if (setValue(«width»,...)) где setValue возвращал int. Теперь там setWidth возвращающий void. Нука нука опиши формальное преобразование, и что там за некомпилящийся бред в результате?


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

Ты дебил или притворяешься?
Для C# есть МСовская хрень, полностью реализующяя стандарт, для плюсов такой хрени нету.

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

> Полный же язык, да и компиляторы, полностью реализующие спецификации есть.

с компиляторами плохо. есть один на насме, и кросс-платформенный инетерпретатор

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

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

А что не так с С++? 27 лет C++ живет потому что исключительно удачный и практичный язык, основа любой современной платформы. Состояние языка и компиляторов уже давно на высоком уровне, достаточно для решения большинства практических задач. Все эти вклады сил и бабла уже многократно себя оправдали, благодаря плюсам имеет большое количество высокопроизводительного удобного софта. Другие современный популярные языки такие как C#/Java заимствовали синтаксис C++ и многие удачные идеи что в очердной раз доказывает успешность C++. А что до тех кто пугает тем что можно отсрелить себе ногу какими-то конструкциями - ну дык, что вы хотели - не отказыватся же от путешествия на машине из-за того что в аварию можно попасть. Уже давно не сталкивался с тем чтобы трудности на проектах рождал бы сам язык.

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

r, хотел бы пообщаться с Вами лично. Можете скинуть мне свою контактную информацию на rtvd собака mail.ru?

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

>Первый _стандарт_ Си++ - это 1997 год, какие еще 27 лет?

Первый ISO стандарт С++. Java ISO не стандартизирована - это не обозначает что на нее нет стандарта.

27 лет с момента появления компилятора С++ - 1983 год.

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


Обычно существует как минимум одна реализация языка которая удовлетворяет его спеке - зачастую это от источника языка. В данном случае не существует ни одной. О чем это говорит?

И второй вопрос - если получается что язык С++ как определено в стандарте _никому_ не нужен - зачем же стандарт разрабатывают никому не нужный?

А если учесть, что в .NET мигель занимался повторной реализацией платформы, в которую M$ вбухал миллиарды...


Мигель осилил с с кучкой людей то во что MS вбухал миллиарды. Вывод - C# вполне осиливаемое для кучки людей. С++ неосиливаемое даже для корпораций типа MS которые если надо могут в бухать миллиарды.

Сколько компиляторов Си++ на свете? А сколько C#? Вот там и воз.


Это к чему еще? Они что всех разработчиков разделили и никому не хватило или что? Или отдельновзятый интел не может справиться?

Без разницы. Компиляторы С# - стандартные. Все 2. Компиляторы С++ нестандартные. Все что есть:)

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

> 27 лет с момента появления компилятора С++ - 1983 год.

Что-то я запутался - речь о стандартах или о первом компиляторе? %)

Мигель осилил с с кучкой людей то во что MS вбухал миллиарды

Он осилил древний стандарт. _Древний_.

Вывод - C# вполне осиливаемое для кучки людей. С++ неосиливаемое даже для корпораций типа MS

Слушай, ты сам-то в это веришь? Что компилятор Си++ для M$ был так же важен, как .NET и что Си++ прям таки корпорацией асиливали и ниасилели? :D

Сколько компиляторов Си++ на свете? А сколько C#? Вот там и воз.

Это к чему еще?

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

Компиляторы С# - стандартные. Все 2. Компиляторы С++ нестандартные. Все что есть:)

Доо. Два компилятора C# поддерживают 2 разных стандарта, офигеть стандартизация %)

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

>Java ISO не стандартизирована - это не обозначает что на нее нет стандарта.

Нет стандарта ISO? Кому нужно это пионерское фуфло?

27 лет с момента появления компилятора С++ - 1983 год.

в 83м году не было (не в реализациях, а в языке вообще) ни множественного наследования, ни шаблонов, ни исключений ни stl. Все эти 27 лет язык развивался. Яве такие темпы и не снились, несмотря на проторенность дорожки. Естественно, реализациям тоже приходилось развиваться.

Обычно существует как минимум одна реализация языка которая удовлетворяет его спеке - зачастую это от источника языка. В данном случае не существует ни одной. О чем это говорит?

О том, что язык простой с урезанными возможностями.

С++ неосиливаемое даже для корпораций типа MS которые если надо могут в бухать миллиарды

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

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

> О том, что язык простой с урезанными возможностями.
Ох лол,
ну да, так и есть. Все языки, кроме c++ - простые, с урезанными возможностями.

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

>Что-то я запутался - речь о стандартах или о первом компиляторе? %)

Это анонимуса спроси. Речь про то что на сегодняшний день нет компилятора реализующего стандарт.

Он осилил древний стандарт. _Древний_.


В каком смысле древний? Отстают от ms. А когда осилят хоть какой нить стандарт С++? Хоть с++98?

Слушай, ты сам-то в это веришь? Что компилятор Си++ для M$ был так же важен, как .NET и что Си++ прям таки корпорацией асиливали и ниасилели? :D


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

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

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

Два компилятора C# поддерживают 2 разных стандарта, офигеть стандартизация %)


А что тут такого? Один отстает - допилят будет поддерживать. Все нормально. Покажи мне хоть один С++ компилятор который поддерживает хоть один стандарт.

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

>Нет стандарта ISO? Кому нужно это пионерское фуфло?

Тем хто не фапает на вывески.

Все эти 27 лет язык развивался.


На бумажке. Реализаций до сих пор нет.

О том, что язык простой с урезанными возможностями.


Ну да конечно. Все остальные в%ебывают по спецификации как дураки. А вот оно как надо - забить на спеку и делать что хошь. И нафига тогда форкгроуп карачится - на них же все плюют.

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

Да он вообще петух знатный,
это надо же всблевнуть, что если язык полностью реализован, то он «простой с урезанными возможностями»

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

>>Слушай, ты сам-то в это веришь? Что компилятор Си++ для M$ был так же важен, как .NET и что Си++ прям таки корпорацией асиливали и ниасилели? :D

Нет.

Ну так и нефиг.

Компилятор С++ для мс был важен.

Важно было, чтобы он был. Его соответствие стандартам особо никого не колебало. Так же, как M$ нужна была своя Java.

Один отстает - допилят будет поддерживать. Все нормально. Покажи мне хоть один С++ компилятор который поддерживает хоть один стандарт.

Что я люблю в стандартах - всегда есть из чего выбрать (с)

Кстати, как там с поддержкой трижды насквозь расово верного C99? %)

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

>Так же, как M$ нужна была своя Java.

MSовская жава вполне соответствовала (не была реализована только RMI библиотека). Конфликт вышел по причине MSовских расширений и бренда.

Его соответствие стандартам особо никого не колебало.


Ты сам то веришь, что конторы которые реализуют компилфторы совсем непарятся соответствием языка - спецификации?

Кстати, как там с поддержкой трижды насквозь расово верного C99?


http://gcc.gnu.org/gcc-4.5/c99status.html

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

> MSовская жава вполне соответствовала (не была реализована только RMI библиотека). Конфликт вышел по причине MSовских расширений и бренда.

Об этом и речь - кто-то попытался расширить Яву под свои нужды и получил по рукам. А вот Си++ расширяли все, кому не лень.

Ты сам то веришь, что конторы которые реализуют компилфторы совсем непарятся соответствием языка - спецификации?

Да. Они парятся над стандартами де-факто (ситуация с C99 как бы намекает).

Кстати, как там с поддержкой трижды насквозь расово верного C99?

http://gcc.gnu.org/gcc-4.5/c99status.html

Так и запишем - стандарт C99 не реализован уже 11 лет. Бида, бида, мы все умрем.

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

>Об этом и речь - кто-то попытался расширить

Ненене - речь не об этом. Речь о том что жабу реализовали стандарт. А в С++ стандарт не реализовал никто. В итоге либо стандарт никому не нужен - и тогда в воркгруппе шизофреники, или он слишком сложный для реализации, что есть факт который признают все.

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

Да. Они парятся над стандартами де-факто


Значит твоя позиция в том что в воркгруп сидят дурочки и придумывают стандарт который никому не нужен?

Бида, бида, мы все умрем.


Мы не умрем при многих условиях. Кое-кто выжил в бухенвальде. Это ж не значит что так жить хорошо.

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

Если бы речь шла о нереализации существенной части стандарта, это имело бы вес.
Факты - это хорошо, но их толкование важнее.
- С++ - сложный язык? Да, с этим никто не спорит.
- Можно ли на нем писать хороший софт? Да, можно.
- Можно ли обойтись его частью, чтобы успешно делать хороший софт? Да, можно.
Некоторые предпочитают тупые ножи, потому что им так спокойнее. Так что теперь, выкинуть все острые?

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

> Некоторые предпочитают тупые ножи, потому что им так спокойнее. Так что теперь, выкинуть все острые?
Это тут при чем? «Тупые ножи» - это все, что не плюсы, да?

Можно ли на нем писать хороший софт? Да, можно.

На любом полном языке можно писать хороший софт.

Можно ли обойтись его частью, чтобы успешно делать хороший софт? Да, можно.


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

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

> Это тут при чем? «Тупые ножи» - это все, что не плюсы, да?
Я не виноват, что ты сачковал уроки русского языка и литературы.

На любом полном языке можно писать хороший софт.

Покажи мне что-нить такое на твоем любимом брэйнфаке.

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

Конечно, можно. Но на С++ это будет удобнее и быстрее.

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

> Покажи мне что-нить такое на твоем любимом брэйнфаке.
У меня только 1 проект на нем, и то closed-source, так что сорри.

Конечно, можно. Но на С++ это будет удобнее и быстрее.

В любой-любой ситуации?
В ынтерпрайзе можно юзать C# и на нем будет быстрее.

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

> У меня только 1 проект на нем, и то closed-source, так что сорри.
Ага, я так и думал.

В любой-любой ситуации?

В ынтерпрайзе можно юзать C# и на нем будет быстрее.


Ты за контекстом совсем не следишь или просто пухнешь на глазах? ;)

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

Ок, я правда не очень хорошо сформулировал ответ.
Вот так вот:
на C++ не всегда будет «удобнее и быстрее», чем на C. Плюс ко всему, всегда найдется язык, на котором разработка для конкретной задачи будет удобнее и быстрее, в сравнении с плюсами

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

Системные вещи. Embedded штучки (портировать библиотеки плюсов а какое-нибудь устройство, наверное, будет геморрно).

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

Пошел я смотреть на этот qross. Пошел глянуть на тест:

http://github.com/0xd34df00d/Qross/blob/master/src/qross/test/main.cpp

54 readFile....

проверка есть только на f.open

65. f.readAll не проверяется - а ведь может не прочитаться.

...

Смотрим где используется

70 runScriptFile

ага - проверяется прочитался ли файл и если нет ту же ошибку наверх.

Два соображения:

1. это что все ошибки в природе будут перечислены в одной иерархии? Эй шеф какие номера заняты? «И на этом можно писать большие программы» (C)....?

2. результат runScript проверяется в 151 main. То есть грубо говоря ошибка которая возникла в глубокой функции по всему стеку вызовов проверяется и выносится кодом в самый верх. Кто там говорил про экономию места на кошках? По ходу получается одну и ту же проверку надо делать в каждом методе по стеку вызовов.

А теперь вернемся к readAll и почему это IO операция взруг стала «безопасной». Обратимся для этого к доке по qt:

This function has no way of reporting errors; returning an empty QByteArray() can mean either that no data was currently available for reading, or that an error occurred.

ОхyETb бля. И может у вас диск сбоит или сетевая шара отпала, а может просто файл пустой.

И это в таком мегафреймворке как Qt! Потенциально ошибочные IO операции забивающие на ошибки.

Зачем исключения говорите?


r ★★★★★
()

Лучше б поддержку D до ума довели, классный язык но нет вменяемого компилятора(((

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