LINUX.ORG.RU
 
MuZHiK-2

Разрешено использование 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.

>>> Официальный анонс


[#] Ответ на: комментарий от oh 01.06.2010 18:38:55  
r

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

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

***** ()
[#] Ответ на: комментарий от JackyTreehorn 01.06.2010 18:30:18  

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

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

anonymous ()
[#] Ответ на: комментарий от JackyTreehorn 01.06.2010 18:38:55  
oh

> Для новых больших проектов никто не возьмет С++
возьмут, возьмут

()
[#] Ответ на: комментарий от anonymous 01.06.2010 18:18:58  
shty
>>-----Цитата---->>

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

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

<<-----Цитата----<<

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

*** ()
[#] Ответ на: комментарий от r 01.06.2010 18:26:17  

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

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

anonymous ()
[#] Ответ на: комментарий от JackyTreehorn 01.06.2010 18:38:55  

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

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

anonymous ()
[#] Ответ на: комментарий от anonymous 01.06.2010 18:38:27  
r

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

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

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

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

***** ()
[#] Ответ на: комментарий от r 01.06.2010 18:41:13  
oh

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

()
[#] Ответ на: комментарий от shty 01.06.2010 18:43:41  

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

anonymous ()
[#] Ответ на: комментарий от r 01.06.2010 18:45:03  

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

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

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

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

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

anonymous ()
[#] Ответ на: комментарий от anonymous 01.06.2010 18:44:36  
oh

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

()
[#] Ответ на: комментарий от oh 01.06.2010 18:39:49  
r

>java? херня

А я и не говорю что язык хороший. Но хотя бы не шизонутый.

***** ()
[#] Ответ на: комментарий от r 01.06.2010 18:47:10  
oh

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

()
[#] Ответ на: комментарий от anonymous 01.06.2010 18:39:49  

>> ASText(Acrobat), std::string(STL), std::wstring(STL), GString(GLib), QString(Qt), CString(MFC), ну и, ессно, char*/wchar_t* - вот полный перечень строковых типов
>А зачем, позвольте узнать?
Ну, даже не знаю как ответить на такой вопрос... "Зачем"... Надо.
Такой вот страшный плагин для Акробата.

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

* ()
[#] Ответ на: комментарий от anonymous 01.06.2010 18:44:06  
r

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

Мозилла:)

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


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

***** ()
[#] Ответ на: комментарий от oh 01.06.2010 18:32:54  
shty
>>-----Цитата---->>

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

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

<<-----Цитата----<<

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

*** ()
[#] Ответ на: комментарий от r 01.06.2010 18:41:13  

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

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

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

anonymous ()
[#] Ответ на: комментарий от r 01.06.2010 18:47:10  

>Но хотя бы не шизонутый.

Он убогий.

*** ()
[#] Ответ на: комментарий от oh 01.06.2010 18:45:56  
r

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

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

***** ()
[#] Ответ на: комментарий от r 01.06.2010 18:45:03  

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

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

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

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

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

anonymous ()
[#] Ответ на: комментарий от anonymous 01.06.2010 18:46:44  
r

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

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

***** ()
[#] Ответ на: комментарий от oh 01.06.2010 18:48:13  
r

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

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

***** ()
[#] Ответ на: комментарий от r 01.06.2010 18:45:03  
EvilBlueBeaver

> Вот стейт о арт - проект мозилла,часть кодинг гайдлайнс относящаяся к плюсам: 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

* ()
[#] Ответ на: комментарий от legolegs 01.06.2010 18:49:11  
r

>Он убогий.

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

***** ()
[#] Ответ на: комментарий от shty 01.06.2010 18:48:34  

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

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

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

anonymous ()
[#] Ответ на: комментарий от oh 01.06.2010 18:42:32  

>возьмут, возьмут
Кстати, да.

* ()
[#] Ответ на: комментарий от anonymous 01.06.2010 18:50:12  
r

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

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

***** ()
[#] Ответ на: комментарий от r 01.06.2010 18:49:33  
oh

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

()
[#] Ответ на: комментарий от r 01.06.2010 18:53:27  
oh

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

()
[#] Ответ на: комментарий от r 01.06.2010 18:52:28  

Разве: 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 01.06.2010 18:56:18  

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

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

Ну тогда и

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

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

anonymous ()
[#] Ответ на: комментарий от anonymous 01.06.2010 19:00:35  
oh

Ну да, а что?

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

()
[#] Ответ на: комментарий от oh 01.06.2010 19:02:38  

> Ну да, а что?

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

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

anonymous ()
[#] Ответ на: комментарий от r 01.06.2010 18:56:18  

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

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

anonymous ()
[#] Ответ на: комментарий от anonymous 01.06.2010 18:58:07  
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


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

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


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

***** ()
[#] Ответ на: комментарий от anonymous 01.06.2010 19:05:19  
oh

В то,
только s/инут/ину/;

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

()
[#] Ответ на: комментарий от anonymous 01.06.2010 19:00:35  
r

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

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

***** ()
[#] Ответ на: комментарий от r 01.06.2010 19:06:47  

>> 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 01.06.2010 19:07:00  

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

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

anonymous ()
[#] Ответ на: комментарий от anonymous 01.06.2010 19:06:30  
r

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

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

***** ()
[#] Ответ на: комментарий от anonymous 01.06.2010 19:09:33  
r

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

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

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


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

***** ()
[#] Ответ на: комментарий от anonymous 01.06.2010 19:12:14  
r

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

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

***** ()
[#] Ответ на: комментарий от r 01.06.2010 19:20:19  

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

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

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

anonymous ()
[#] Ответ на: комментарий от r 01.06.2010 19:22:55  

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

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

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

anonymous ()
[#] Ответ на: комментарий от anonymous 01.06.2010 19:26:03  
EvilBlueBeaver

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

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

* ()
[#] Ответ на: комментарий от anonymous 01.06.2010 19:24:54  
r

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

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

***** ()
[#] Ответ на: комментарий от r 01.06.2010 19:22:12  

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

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

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

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

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

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

anonymous ()
[#] Ответ на: комментарий от anonymous 01.06.2010 19:26:03  
r

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

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

***** ()
[#] Ответ на: комментарий от r 01.06.2010 18:40:36  

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

()
[#] Ответ на: комментарий от r 01.06.2010 19:29:05  

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

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

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

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

anonymous ()