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)
Ответ на: комментарий от lester

> а теперь выкинь переменную из своего примера «if(f(arg) != -1)» и сравни две команды над регистрами с одной со стеком

Бида-бида. Когда у функции есть собственные локальные переменные (а они есть почти всегда), эта команда будет в обоих случаях. И почти всегда будет экономия за счет того, что не нужно проверять возвращаемое значение на ошибки.

при словленном исключении идет его проброска( бросок другого ) - тоже нереальный случай?


К.О. подсказывает: если исключения кидаются редко, то наверное и процесс их обработки (включая возможные многочисленные перебрасывания) случается так же редко?

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

>Ждём нормальный clang-llvm в Линуксе.

Выше по треду говорили, что он на C++ написан.

linuxfan
()

С++98 ОЯЕБУ

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

> Ждём нормальный clang-llvm в Линуксе.

он же вроде на С++?

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

[quote]Ну всё, после этого GCC точно R.I.P. Использовать C++ для написания компилятора это то же самое, что использовать его для системного программирования. Ждём нормальный clang-llvm в Линуксе.[/quote] [br] А чем собственно плох с++ для использования его для системного программирования и как это связано с написанием на нем компилятора?

anonymous
()

Бои техноидов в треде!

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

> К.О. подсказывает: если исключения кидаются редко, то наверное и процесс их обработки (включая возможные многочисленные перебрасывания) случается так же редко?

может К.О. посмотрит сначала на код, а потом сделает выводы?

lester ★★★★
()

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

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

> процессор не вырезает блоки памяти, а потом склеивает, а копирует целиком

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

запомни: catch - сами по себе, throw - сами по себе

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


Это лишь характеризует автора примера как порядочного чудака :)

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

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

Вы очевидно не сталкивались с суровым и беспощадным Ынтырпрайзом, когда нужно соблюдать два правила:

1) Лишь бы работало

2) Должно быть сделано вчера

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

> Использовать C++ для написания компилятора это то же самое, что использовать его для системного программирования

в целом справедливо, но написано так, как будто в этом есть что-то плохое

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

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

Я конечно не особо силен в теме, но где-то слышал про фичу look-ahead, которая позволяет предугадать что загружать в кеш кроме того, что непосредственно потребовалось для выполнения для собственно усорения последующей работы. Это так или я ошибаюсь?

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

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

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

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

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

Это лишь характеризует автора примера как порядочного чудака :)


если исключениями не пользоваться, то они ничего не стоят - да

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

to EvilBlueBeaver - я сторонник плюсов, и CMake мне тоже нравится

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

очевидно, что c++ — это плохо.

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

>Вы очевидно не сталкивались с суровым и беспощадным Ынтырпрайзом, когда нужно соблюдать два правила:

1) Лишь бы работало

2) Должно быть сделано вчера

Надеюсь, ты написал это, чтобы просто потроллить.

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

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

Да никто же и не спорит, что исключения нужны там где они нужны (привет К.О.). Но никто не застрахован от неправильного их использования. Иесли с кодами ошибок в GCC все более менее отлажено как я понимаю, то с ислючениями будет только больше мороки, чем реальной пользы. По крайней мере на данном этапе.

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

> Надеюсь, ты написал это, чтобы просто потроллить.

Ну в какой-то мере да, но все же Ынтырпрайз (именно Ы) местного разлива суров и беспощаден.

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

> На Си на самом деле можно те же приемы использовать, что и на плюсах.

Я знаю, и сам предпочитаю Pure C где только можно. Но это же не значит, что стоит отказываться от языков высокого уровня совсем - если удобнее разработчикам G++ писать код на C++, то почему бы, собственно и нет? Думаю, эти разработчики знают C++ достаточно хорошо, чтобы избежать тех проблем, за которые этот язык многие не любят. :)

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

> throw делают при обнаружении исключительной (редко возникающей) ситуации

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

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

> вот только как написание компилятора на C++ скажется на его портабельности?

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

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

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

Ты тупишь. Компилятор старается разместить код throw в конце функции. Поэтому часто выполняемый код не разбавлен кодом обработки редких ситуаций, и следовательно лучше кэшируется. Чтобы добиться аналогичного эффекта с обычной проверкой ошибок, придется использовать прагмы или profile-guided оптимизацию (то есть тратить усилия на то, что при использовании исключений получается автоматически и без дополнительных трудозатрат).

если исключениями не пользоваться, то они ничего не стоят - да


Если пользоваться ими по прямому назначению: для обработки редких ситуаций.

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

> некоторые пользуются, чтоб выйти из вложенных блоков - т.е. вместо break/goto

Очень оригинальный метод использования. :))

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

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

разумное решение

множественного наследование - в этом списке лишнее

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

Какой смысл спорить о том, насколько процентов, на один или целых полтора программа станет медленнее работать с использованием исключений, если у компилятора использование исключений всё равно НЕ будет узким местом?

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

> Печально. Жду огромного количества косяков в gcc :(

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

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

>>>решение разумно и отчасти вытекает из того, что GCC уже слинкован , начиная с версии 4.4 с библиотекой libstdc++ (за счет Graphite [cloog,ppl,gmpxx])

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

Утешай себя и дальше.

У ООП только один недостаток: Исключения! Если от них избавиться - проблем становиться существенно меньше.

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

>> ...и исключений...

А что не так в исключениях? Нет, мне на самом деле интересно, я просто не знаю, насколько хорошо они реализованы в C++.

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

Короче: нет методи рефакторинга проектов с исключениями.

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

> throw делают при любой ситуации, которая не вписывается в идеальный ход работы программы. Поэтому далеко не факт, что такие ситуации будут редко возникать.

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

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

> У ООП только один недостаток: Исключения!

Человек, ты дурак, да?

Какое вообще отношение исключения имеют к ООП?

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

> Ты тупишь

давай уже без оскорблений

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


если в функции не используются try/catch, а они нужны везде - если кидаешь исключения, то и должен их отлавливать

Если пользоваться ими по прямому назначению: для обработки редких ситуаций.


если б ими только так и пользовались

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

> вот только как написание компилятора на C++ скажется на его портабельности?

думаю, ему все равно нужна «своя» libsdtc++ :)

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

> И если часто возникающая ситуация не предусмотрена этим самым основным ходом...

И как она должна быть предусмотрена? Ах да, проверкой кода возврата функций с помощью if... ;)

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

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

разумное решение

множественного наследование - в этом списке лишнее

В этом списке всё лишнее.

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

> я понимаю, что goto - стремная штука, но применять для этого исключение - изврат

В общем-то и goto в таком случае - изврат, break будет более правильным.

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

>> я понимаю, что goto - стремная штука, но применять для этого исключение - изврат

В общем-то и goto в таком случае - изврат, break будет более правильным.

У goto - одна ниша. Освобождать ресурсы, как в ядре.

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

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

разумное решение

множественного наследование - в этом списке лишнее

В этом списке всё лишнее.

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

anonymous
()

Смешно слышать в треде ыкспертов, которых бы в разработку GCC даже бы не взяли.

Ясно сказано

We should use features that are relatively easy for C programmers to understand and relatively hard for new C++ programmers to misuse.

Проблема в том, чтобы косяков не наплодить, причем в связке с кодом на С, в котором нет исключений. А они такты считают... Всем по большому счету все равно на скорость работы компилятора. В том числе и мне на gentoo. Главное надежность компилятора и скорость и надежность генерируемого кода. А на С действительно труд не очень эффективен, вон как Gtk пилят. Так там хоть ABI важен, а во внутренностях компилятора бинарная совместимость не нужна.

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