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

> С какой стати? Косяк-то в библиотеке, там и надо ловить. Функция якобы тривиальна, не так ли?

А в библиотеке это не косяк а изменение функциональности и она вообще другой конторой разрабатывается.

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

> а за Haskell кто стоит?

Мыкрософт. Что как бэ намекает, что лучше держаться подальше.

насколько я понимаю сам мелкософт не при делах, скорее уж сотрудники 4fun

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

> Допустим. Все равно это не связано с «шаблоны не трогать».

Кто сказал «не трогать»? Трогать то можно, если это stl. Boost трогать нельзя.

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

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

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

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

>Остальное то же можно найти но в части применения их для корпорация я сомневаюсь и потому мне лень тратить время.

Там что - гдето запрещены исключения или генерики?

Ты читал вообще что там написано?

Вот стейт о арт - проект мозилла,часть кодинг гайдлайнс относящаяся к плюсам: https://developer.mozilla.org/en/C___Portability_Guide

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

А что? В перл есть херня типа «7 реализаций типа строка»?
То что перл даёт большую свободу для оформления безусловно можно обратить против сил добра (пример тому однострочник, упомянутый ранее в треде), но как правило это идет только в плюс

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

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

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

>> Остальное то же можно найти но в части применения их для корпорация я сомневаюсь и потому мне лень тратить время.

Там что - гдето запрещены исключения или генерики?

Ты читал вообще что там написано?

Вот стейт о арт - проект мозилла,часть кодинг гайдлайнс относящаяся к плюсам: https://developer.mozilla.org/en/C___Portability_Guide

Читал. Присмотрись к ограничениям в IO.

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

возьмут и ВСОСТУ как обычно, и скажут про энетерпрайз

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

ИМХО, может и лучше чем плюсы, но что на нем писать-то? на шарпе вон энтерпрайз заменить можно, вместо плюсов

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

ASText(Acrobat), std::string(STL), std::wstring(STL), GString(GLib), QString(Qt), CString(MFC), ну и, ессно, char*/wchar_t* - вот полный перечень строковых типов

А зачем, позвольте узнать?

Ну, даже не знаю как ответить на такой вопрос... «Зачем»... Надо.
Такой вот страшный плагин для Акробата.

Кстати, это заодно и небольшая иллюстрация того бардака, который может получиться от смешения C и С++

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

>Кто сказал «не трогать»?

Мозилла:)

Трогать то можно, если это stl. Boost трогать нельзя.


А самому можно? А до какой степени?:)

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

> нет, не пропадут, но гарантии никакой

Еще раз. Гарантии у тебя и так НИКАКОЙ нет, если ты не используешь .NET. Свободный софт не содержит гарантий

есть гарантия, если использую С, С++, Java etc., и гарантия эта выражается в большом количестве реализованных систем и наличии альтернативных реализаций компиляторов (назовём это так)

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

>>Например, очень часто в perl

Ну вы поняли?:)

Если по-честному, то там это продиктовано необходимостью: строки могут содержать что угодно, не экранировать же все разделители в строке.

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

>В перл есть херня типа «7 реализаций типа строка»?

Нет в этом смысле он цельный. Но одноразовый:)

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

>>Остальное то же можно найти но в части применения их для корпорация я сомневаюсь и потому мне лень тратить время.

Там что - гдето запрещены исключения или генерики?

Ты читал вообще что там написано?

Вот стейт о арт - проект мозилла,часть кодинг гайдлайнс относящаяся к плюсам: https://developer.mozilla.org/en/C___Portability_Guide

Это просто пример нормального кодинг стандарта. Почитай, может понравиться и своим присоветуешь. Большинство пунктов - реально обосновано.

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

>Читал. Присмотрись к ограничениям в IO.

К которым? Читать файлы учитывая кодироку? ЗАкрывать открытые файлы? Не выводить паролей в логи? Да - это видать фичи языка так насолили.

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

>на шарпе вон энтерпрайз заменить можно, вместо плюсов

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

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

> Вот стейт о арт - проект мозилла,часть кодинг гайдлайнс относящаяся к плюсам: https://developer.mozilla.org/en/C___Portability_Guide

Зачетный однако язык - плюсы

Don't use Run-time Type Information

Don't use exceptions

Don't use static constructors

и на сладкое

Don't use C++ standard library features, including iostream

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

>Он убогий.

Он устаревший. Но он сделан грамотно. В с++ все равно нету концепций которых жаве не хватает. Это совсем не ариффметика указателей.

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

> есть гарантия, если использую С, С++, Java etc., и гарантия эта выражается в большом количестве реализованных систем и наличии альтернативных реализаций компиляторов (назовём это так)

А вы чего боитесь? Что проект перестанет развиваться? Этого точно не случится, потому что Haskell уже перешёл ту черту, за которой отмирают новые языки, да и создавался он как объединение тогда существующих языков того же вида.

Единственное, что может быть, так это трудность в сопровождении, т.к. людей с таким опытом всё-таки пока мало (но есть тенденция к распространению).

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

>Большинство пунктов - реально обосновано.

Большинство пунтктов там показывает что С++ говно. И нужны чтобы в это говно не вступить.

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

Мигель врывается в тред. Теперь здесь будет еще и моносрачь

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

Разве: Do not create multiple buffered wrappers on an InputStream Do not catch NullPointerException Do not synchronize on the class object returned by getClass() Do not use Thread.stop() to terminate threads не ограничения?

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

>>Большинство пунктов - реально обосновано.

Большинство пунтктов там показывает что С++ говно. И нужны чтобы в это говно не вступить.

Ну тогда и

https://www.securecoding.cert.org/confluence/display/java/The+CERT+Oracle+Sec...

показывает что java говно. Ну и так далее.

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

> Ну да, а что?

Ты кажется не истинут тут хочешь выяснить, а r «отомстить», который тебя обидел

Хм... о чем это? Это вообще в то окно?

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

>Большинство пунтктов там показывает что С++ говно. И нужны чтобы в это говно не вступить.

4.2. Большинство пунктов из-за несовместимости реализаций.

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

>Do not create multiple buffered wrappers on an InputStream

Ничего страшного не случится. Просто бессмысленно.

Do not catch NullPointerException


Ошибки в коде надо испралять, а не перехватывать.

Do not synchronize on the class object returned by getClass()


Чтобы не получить дедлока между парентом и наследником. Ничего страшного не произойдет если осознаешщь что именно возвращает getClass.

Do not use Thread.stop() to terminate threads


А ты знаешь почему?

не ограничения?


Языка? Серьезно?

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

>показывает что java говно. Ну и так далее.

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

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

>> Do not create multiple buffered wrappers on an InputStream

Ничего страшного не случится. Просто бессмысленно.

Do not catch NullPointerException

Ошибки в коде надо испралять, а не перехватывать.

Do not synchronize on the class object returned by getClass()

Чтобы не получить дедлока между парентом и наследником. Ничего страшного не произойдет если осознаешщь что именно возвращает getClass.

Do not use Thread.stop() to terminate threads

А ты знаешь почему?

не ограничения?

Языка? Серьезно?

Причем тут языка. Эти ограничения при программировании на java. Их же нет при программирование на другом языке. Так что в хорошем кодинг стандарте ограничения есть всегда.

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

> иначе зачсем ты так к жаббе прицепился?

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

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

>4.2. Большинство пунктов из-за несовместимости реализаций.

Какой потрясающий язык. Реализация так сложна что даже мегаконторы вкладывающиеся в GCC или Микрософт со всем своим баблом до сих пор не асилил реализовать.

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

>Эти ограничения при программировании на java

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

Так что в хорошем кодинг стандарте ограничения есть всегда.


Там не ограничения имспользования языка - там рекомендация не делать детских ошибок. 95% тех пунктов применимы к любому языку.

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

>Но уже здесь стало ясно что он говорит о каком то мифическом ограничении языка,

Миф по ссылке. Прямо запрещающий пользоваться фичами языка.

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

>>4.2. Большинство пунктов из-за несовместимости реализаций.

Какой потрясающий язык. Реализация так сложна что даже мегаконторы вкладывающиеся в GCC или Микрософт со всем своим баблом до сих пор не асилил реализовать.

Ну да. Реализация сложна. Именно при разработке с++ разработчики gcc поняли несостоятельность теории о компиляторах. Но простота реализации языка - это критерий n-й по счету в оценках достоинства языка.

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

>> Но уже здесь стало ясно что он говорит о каком то мифическом ограничении языка,

Миф по ссылке. Прямо запрещающий пользоваться фичами языка.

И? Я тебе привел такие же по ява? Или NullPointerExcaption - не фича?

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

> И? Я тебе привел такие же по ява? Или NullPointerExcaption - не фича?

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

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

>Но простота реализации языка - это критерий n-й по счету в оценках достоинства языка.

Это если он в принципе реализуем. А не когда через 27 лет все еще нет ни одной реализации. Фраза типа «в 2010 году оносновные реализации сделали _почти_ все фичи стандарта 1998 года» доставляет. За это время такие проекты как делфи сдохнуть успели, вместе с мегакорпорациями.

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

>>Эти ограничения при программировании на java

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

Ну покажи мне обработку NUllPointerException и его обработку в lisp'е.

Так что в хорошем кодинг стандарте ограничения есть всегда.

Там не ограничения имспользования языка - там рекомендация не делать детских ошибок. 95% тех пунктов применимы к любому языку.

Таки согласен, что 5 - только к ява? Уже хорошо.

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

>Или NullPointerExcaption - не фича?

Ей что пользоваться нельзя? Правда? Там для детей написано что если у тебя, ребенак, NPE - ищи почему, а не пиши как канадский программист catch NPE.

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

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

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

>>Но простота реализации языка - это критерий n-й по счету в оценках достоинства языка.

Это если он в принципе реализуем. А не когда через 27 лет все еще нет ни одной реализации. Фраза типа «в 2010 году оносновные реализации сделали _почти_ все фичи стандарта 1998 года» доставляет. За это время такие проекты как делфи сдохнуть успели, вместе с мегакорпорациями.

То есть ты хочешь сказать, что сейчас нет реализаций?

Мда.. Логика однако. То что они не соотвествуют - дело тринадесятое. Может и задачи такой у них нет. Легче стандарт поменять.

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