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)

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

false преобразуется к 0, а 0 может быть передан как указатель. А 1 к указателю уже не преобразуется.

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

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

да ты просто экстремал крайностей.

AVL2 ★★★★★
()

Ну и зафиг окончательно загонять гцц в ловушку самообрушающегося кодинга?

Есть хаскель, что еще надо?

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

> да ты просто экстремал крайностей.

все никак не перейду с С на С++ полностью, не тянет что-то писать шаблоны и кидать исключения

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

/opt/sunstudio12.1/bin/CC -c 1.cc «1.cc», line 3: Warning (Anachronism): main() must have a return type of int. «1.cc», line 7: Error: «main()» cannot return a value. 1 Error(s) and 1 Warning(s) detected.

пользуйтесь нормальными тулзами ;)

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

> пользуйтесь нормальными тулзами ;)

Мне если честно пофиг на самом деле. Но гцц тоже ворнинг выкидывает на void main.

А так я просто неправильно код скопировал.

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

> Кстати, где лисперы?

А на кой они тут? Уж Лисп то из GCC, увы, никуда еще долго не денется. Потому и лучше llvm с его tblgen и clang поверх, что там никакими лиспами и не пахнет.

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

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

но с++ это как раз тот уникальный случай, когда весь ЯП не по назначению...

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

gcc - монополист (в *nix системах) и люди все равно будут пользоваться им все зависимости от желания, так что привлекать никого не надо.

llvm на пятки наступает. clang++ уже компилирует буст без хаков.

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

> А смесь С и С++ - ну ты понял.

По моим ощущениям, до 90% программ, разработанных якобы на C++ - это именно такая смесь.

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

> нет, goto правильнее, чем стопицот break'ов

И то, и другое не совсем идеально. Идеален был бы break на метку. (Т.е. такой узкоспециализированный ограниченный goto). Кстати, в каком-то языке он есть, но в каком - мой склероз мешает вспомнить...

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

> исключения и шаблоны крайне полезны для написания надежного и расширяемого кода

в том то и проблема, что over 90% якобы программистов Си++ не умеют использовать ни того, ни другого

northerner ★★★
()

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

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

> в варианте номер 2? очень интересно.

Ну да, так и происходит. Впрочем, дальше оно приводится к std::string. И потом еще и к std::string &.

См. rtvd * (31.05.2010 20:45:53)

Правда, не вижу здесь ничего интересного. Просто срань а не язык программирования. «С» значительно менее уродлив.

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

> надо чтобы он был вменяемо кроссплатформенный

На какой платформе он Вам нужен? :-) Хотя бы теоретически.

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

Касательно исключений я что-то я не очень понял, как же это так внезапно кусок кода вывалится из кэша и туда не попадет, если он исполнятся на каждой итерации?

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

> осталось переписать ведро на c++ и выкинуть glibc. c++, java и mono — наше фсё!

Простите, но как это вы можете ставить замечательный язык и прогрессивную платформу в один ряд с этими богомерзкими плюсами? А вообще даёшь gcc на лиспе!

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

>надо чтобы он был вменяемо кроссплатформенный

вообщето я имел в виду язык, на котором пишется сам компилятор, а не замену всем языкам пограммирования.

По моему, хаскель не сильно отстает в портабельности кода от СИ.

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

>в том то и проблема, что over 90% якобы программистов Си++ не умеют использовать ни того, ни другого

нк stl же используют, а он есть благодаря шаблонам. С исключениями сложнее.

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

надо чтобы он был вменяемо кроссплатформенный

А сейчас он невменяемо кроссплатформенный?



Почитал обсуждение. Было б три руки - был бы тройной facepalm... А так...

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

stl же используют

Так и монады используют :)

Проблема жеж не в использовании, а в понимании того что используется.

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

надо чтобы он был вменяемо кроссплатформенный

На какой платформе он Вам нужен? :-) Хотя бы теоретически.

почему теоретически, мне нужен практически, сейчас под проект, платформы: Solaris, Windows, Linux

и нужен - это не значит что «я собрал компилятор, ура», нужны ide, инструменты для тестирования, профилирования etc., по крайней мере некоторое время назад с этим было довольно туго

и да, меня смущает зоопарк компиляторов

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

вообщето я имел в виду язык, на котором пишется сам компилятор, а не замену всем языкам пограммирования.

эхм, ну возможно :)

По моему, хаскель не сильно отстает в портабельности кода от СИ.

не знаю как в настоящий момент, не так давно отставал существенно

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

надо чтобы он был вменяемо кроссплатформенный

А сейчас он невменяемо кроссплатформенный?

по сравнению с C, C++, Java, и даже Python - куда как менее вменяемый

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

и да, меня смущает зоопарк компиляторов

А зоопарк компиляторов C/C++/Pascal/Lisp/etc Вас уже не смущает? :)
Я, в общем-то, понимаю: GHC-с-плюшками vs остальные-реализации-haskell98 - как-то так.

нужны ide, инструменты для тестирования, профилирования etc.,

Ну так вроде eclipse + плагины «для тестирования, профилирования etc., »
на всех трех доступен.

Хотя лично я не в неземном восторге от eclipse.

yaws
()

C++0x, использование множественного наследования, шаблонов (тех, которые не входят в стандартную библиотеку C++) и исключений, скорее всего, будет запрещено.


Очень логично и правильно. Хотя зачем в Си-проекте такой покоцанный С++ - все равно неясно: вроде как лишняя сущность :)


Хех, 8ю каментами «там» покрыли весь спектр мнений, изложенный на 5 страницах обсуждения «здесь» :)

yaws
()

Это что gcc будут на Си++ переписывать? Или просто Си++ будет использоваться дополнительно, вместе с Си? Если первое, то решение глупое, если второе, то пускай.

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

> По моему, хаскель не сильно отстает в портабельности кода от СИ.

Где хацкель для PIC16? Ну или хотя бы под 16битный DOS?

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

> А вообще даёшь gcc на лиспе!

Там и так внутри лиспа много больше чем нужно (см. -fdump-tree-all, -fdump-rtl-all).

Я уж не говорю про извращения вроде этого: http://gcc.gnu.org/wiki/MiddleEndLispTranslator

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

>При использовании исключения нужно позаботиться всего о двух местах в коде — том, которое генерирует исключение и том, которое обрабатывает

В плюсах то? Серьезно?

void f() {
int * i = new/malloc/....
g(); //maybe exception
//really?
}

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

>Кстати, где лисперы?

Жрут попкорн. А ты думал?

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

> Кстати, где лисперы?

Здесь они, они за С++ с шаблонами и исключениями и против «С с классами».

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

> lester и Manhunt напоминают своим спором Mauhuur и R00T, только вот без мата пока обходятся :)

скучно....

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

>вообщето я имел в виду язык, на котором пишется сам компилятор, а не замену всем языкам пограммирования.

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

r ★★★★★
()

Эх, а ведь было времечко...

Входишь в Машинный Зал (именно так, с заглавных, ибо вокруг-полубоги в белых халатах) с колодой перфокарт. Накануне - веселье, страшно болит башка опосля двух бытылок рома Puerto Rico с парой сокурсников и двумя девочками с ПМПУ. По сему делалось в конце празднества, что называется, «на коленке». Результат предсказуем за ранее... Вставляешь колоду в считыватель и... Есть-таки Бог на свете! Через секунду карты изрезаны в лапшу. Оправдываешься перед завлабом, мол не успел сдублировать. Тот, свирепея, посылает к тов. Валькову. «Проси разрешения на пересдачу, иначе - не зачёт...» Прибегаешь к Валькову, трясёшь перед ним искромсаной колодой, трясёшься сам... Тот, помарщиваясь от запаха перегара, зачитывает нотацию, но разрешение пересдать таки даёт. Даёшь себе слово - больше ни грамма, только учебники... До следущей попытки сдачи.

А вы тут устроили - С, С++, хаскель, лисп... Скучно всё это, господа. Надо просто владеть инструментарием. И бутылки держать подалее, тады с любым языком проблем не будет! ;-)

P.S. «Шутка. Шутка это всё, господа!» © О бедном гусаре замолвите слово.

R_Valery ★★★
()

Я вот только не понимаю, зачем компилятор писать на императивных языках? По моему гораздо лучше подходит чистый функциональный язык, где можно сосредоточься на input/output в функциях и иметь гарантию того, что не будет никаких багов из-за возможности свободного обращения к памяти. Или я не прав?

EvgenijM86
()
Ответ на: Эх, а ведь было времечко... от R_Valery

Вы вероятно до сих пор пользуетесь досом.
А ещё мобильники вошли в обиход и все пользуются gps-ом.
С упрощением средства разработки растет и продуктивность и скорость разработки.

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

>>При использовании исключения нужно позаботиться всего о двух местах в коде — том, которое генерирует исключение и том, которое обрабатывает

В плюсах то? Серьезно?


void f() {

int * i = new/malloc/....


g(); //maybe exception


//really?


}



Ну так сдуру и *** сломать можно. Я ж ниже написал, что вся инициализация и деинициализация (в том числе выделение и освобождение памяти) должна быть в конструкторах/деструкторах объектов, иначе это фигня, а не ООП.

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

> Я вот только не понимаю, зачем компилятор писать на императивных языках? По моему гораздо лучше подходит чистый функциональный язык, где можно сосредоточься на input/output в функциях и иметь гарантию того, что не будет никаких багов из-за возможности свободного обращения к памяти. Или я не прав?

Большинству вменяемых компиляторов (C или C++) более 15 лет, а тогда еще ресурсы были в цене, а для ФП не было таких эффективных трансляторов.

Но сегодня это было бы хорошо: моделируешь целевую платформу, и потом выполняешь обычные алгебраические преобразования. Может быть, даже можно проводить суперкомпиляцию...

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

> и нужен - это не значит что «я собрал компилятор, ура», нужны ide, инструменты для тестирования, профилирования etc., по крайней мере некоторое время назад с этим было довольно туго

emacs давно кроссплатформенный

и да, меня смущает зоопарк компиляторов


Ну, что я могу сделать-то?

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

> почему теоретически, мне нужен практически, сейчас под проект, платформы: Solaris, Windows, Linux

Они есть под все эти платформы.

и нужен - это не значит что «я собрал компилятор, ура», нужны ide, инструменты для тестирования, профилирования etc., по крайней мере некоторое время назад с этим было довольно туго

Только вот IDE нормальной нет, а тестирование есть уже давно, вот недавно вышел фреймворк для тестирования, и ещё один для бенчмарков. Поддержка профилирования тоже хорошая: HPC, ThreadScope.

и да, меня смущает зоопарк компиляторов

GHC — пока единственный «серьёзный» компялятор. Hugs не умеет в объектный код, В YHC много чего нет. Остальные вообще больше исследовательские. Не знаю, где вы там увидели зоопарк...

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

> По моему, хаскель не сильно отстает в портабельности кода от СИ.

Ну, GHC может транслировать свой код в портируемый Cи, но я совершенно не представляю, как это будет выглядеть на встраиваемых устройствах, например. Как будет обеспечиваться поддержка всех «продвинутых» возможностей?

anonymous
()

Зря они это всё-таки, по-моему.

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

>Для начала, было бы интересно узнать, когда не хватает дефолтного аллокатора?

Во всех случаях, когда приходится создавать большое число маленьких короткоживущих объектов вперемешку с парой-тройкой долгоживущих. В общем, прикручивание пулов к STL'ным объектам дело практически гиблое.

Тем, что аллокатор является свойством класса, а не экземпляра?

Во-первых, тем, что аллокатор не имеет состояния. Может я чего не понимаю, но сделать std::string, располагающийся в локальном пуле, не очень получится. Во-вторых, std::*<,allocator1> и std::*<allocator2> — разные типы с прямо вытекающей отсюда невозможностью пользоваться готовыми операторами сравнения. Бредятина в стиле це-крест-крест.

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

> Или я не прав?

Очень, очень не прав. Ввод/вывод в компиляторе случается далеко не только при чтении исходника и записи объектника. Функциональщина для компиляторов абсолютно не приспособлена.

Да что там ввод/вывод. Основная структура данных в компиляторе - это граф, а вовсе не дерево, как любят втирать нечистые на руку функциональщики. Графы на функциональщине представимы дюже похабно.

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

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

anonymous
()

> ...мы должны минимизировать список разрешённых возможностей С++, чтобы...

Уже смешно. Путь настоящего джедая-костыляя - потихоньку курочить и приматывать на изоленте, пока эта помойка не разрастётся до состояния «проще заново переписать». :)
Возможности сипипей настолько кардинально отличаются от «простоси», что приделывать сбоку «как бы классы» - мудачество чистой воды. Архитектура должна сразу опираться на ООП/шаблоны/буст, чтобы вообще имел смысл использовать С++ (а чем кроме этого он хорош??).

Хотя я всё равно против сипипей как пром.языка: этот «ассемблер с классами» - бомба во всех смыслах, что до сих пор (напоминаю - 21 век) ошибки «перезаписи буфера» являются новостью.
Нужно развивать D, даже «сам Александреску» вполне одобряет этот язык (и критикует С++). Удобнее/защищённее язык -> качественнее проги -> быстрее нарастание программной базы -> мир во всём мире. А С++ нас засасывает как болото - чем больше на нём пишут, тем глубже ППЦ.

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