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 ()

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

Просто плюсосрач, яп-срач, компиляторо-срач и нет лисперов?

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

Сделай миру хорошо, забудь о программировании. В любой,хоть чуть-чуть, адекватной книжке, где упоминаются искючения, сказано, что их _НЕЛЬЗЯ_ использовать в качестве _УПРАВЛЯЮЩИХ_ конструкций, а ты ими выходишь из циклов, функций(в своём примере). Естественно у тебя всё тупит, только это не исключения тупят, а ты.

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

> Сделай миру хорошо, забудь о программировании. В любой,хоть чуть-чуть, адекватной книжке, где упоминаются искючения, сказано, что их _НЕЛЬЗЯ_ использовать в качестве _УПРАВЛЯЮЩИХ_ конструкций, а ты ими выходишь из циклов, функций(в своём примере). Естественно у тебя всё тупит, только это не исключения тупят, а ты.

ГЫ! То есть исключения должны быть только внутри функций и только одного типа?

anonymous ()

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

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

Чего спорить то?! Время покажет, а кто хочет - тот поможет. Все просто

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

> любой,хоть чуть-чуть, адекватной книжке, где упоминаются искючения, сказано, что их _НЕЛЬЗЯ_ использовать в качестве _УПРАВЛЯЮЩИХ_ конструкций, а ты ими выходишь из циклов, функций(в своём примере).

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

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

> с кодами ошибок в GCC все более менее отлажено

Ну да, конечно. Помню, как оно при нехватке памяти выдавало что-то типа «undefined identifier AKJD».

anonymous ()

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

Это говорит о предполагаемой квалификации C++разработчиков GCC. Как можно вообще браться за применение С++ в сложном проекте, не владея такими элементарными вещами? Лучше бы по другому сформулировали - программисты на С++, не владеющие множественным наследованием и т.п., к разработке не допускаются.

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

> А STL разве не кривой и убогий?

Гораздо прямее всего, что можно налабать за денёк-другой на коленке.

Взять, к примеру, его на голову больную концепцию аллокаторов.


Для начала, было бы интересно узнать, когда не хватает дефолтного аллокатора? И чем конкретно не устраивает stl-ный подход к аллокаторам? Тем, что аллокатор является свойством класса, а не экземпляра?

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

> Ну... в году в 92-93 на Корветах на BASIC goto мне совсем извратом не казался... ;)

Мне году в 96-м в GWBASIC. Но там без вариантов, вроде, было. :)

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

>> с кодами ошибок в GCC все более менее отлажено

Ну да, конечно. Помню, как оно при нехватке памяти выдавало что-то типа «undefined identifier AKJD».

Как местные анонимусы любят выдирать фразы из контекста. Привожу всю фразу...

Иесли с кодами ошибок в GCC все более менее отлажено как я понимаю...

...если...

...более менее...

... как я понимаю...

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

>> А STL разве не кривой и убогий?

Гораздо прямее всего, что можно налабать за денёк-другой на коленке.

Взять, к примеру, его на голову больную концепцию аллокаторов.

Для начала, было бы интересно узнать, когда не хватает дефолтного аллокатора? И чем конкретно не устраивает stl-ный подход к аллокаторам? Тем, что аллокатор является свойством класса, а не экземпляра?

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

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

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

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

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

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

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

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

К томуже в твоём коде исключения были как-раз таки выходом из функций, потому их обработка и не была вынесена компилятором в конец кода.

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

> А некоторые предлагают наждачкой подтираться, давайте запретим наждачку?

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

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

> К томуже в твоём коде исключения были как-раз таки выходом из функций, потому их обработка и не была вынесена компилятором в конец кода.

там где не было try/catch - да, я это и не отрицал

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

>>Речь вроде идёт о неюзании С++0х фич. Об остальных идёт речь, что это не простые вещи. Об их запрете не упоминается...

also seems overly aggressive to me

Теперь понял, почему эти вещи будут считаться не Ъ?

MuZHiK-2 ★★★★ ()

RIP, my dear GCC

Любителям C++ посвящается вопрос:

Что будет в этой программе


#include <string>
#include <iostream>

bool foo(const std::string &str) {
std::cout << str.length() << std::endl;
}

int main(int argc, char **argv) {
std::cout << foo( X )-1 << std::endl;
}


В случаях:

1. X это true
2. X это false
3. X это «true»
4. X это «false»

:-)

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

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

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

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

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

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

Многокилометровые нет. Простые, или стандартные да. Наследование сразу от трех классов рулит. тут ты прав!

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

Ну так никто и не спорит, что при _НЕПРАВИЛЬНОМ_ использовании исключений, они не будут тупить, но при правильном они не замедляют код, увеличивают размер блоба - да, но при штатной работе этот код не выполняется, при нештатной - извините, пишите баг-репорты.

Ivan_qrt ★★★★★ ()
Ответ на: RIP, my dear GCC от rtvd

> 1. X это true

2. X это false


не скомпилируется

3. X это «true»

4. X это «false»



выведет 4/5 и мусорное значение

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

>>Многокилометровые нет.

А вот это есть делать любители. Потом смотреть и понимать этот код - лучше застрелиться.

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

> Ну так никто и не спорит, что при _НЕПРАВИЛЬНОМ_ использовании исключений, они не будут тупить,

ну на том и договорились

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

>> Многокилометровые нет.

А вот это есть делать любители. Потом смотреть и понимать этот код - лучше застрелиться.

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

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

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

А если авторы библиотеки халтурят, то не исключения в этом виноваты.

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

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

А если авторы библиотеки халтурят, то не исключения в этом виноваты.

Еще раз. Здесь проблема не в возможности накосячить а в отсутствии методологии рефакторинга проектов с исключениями и сложными шаблонами. Что НЕИЗМЕННО приводит заранее известному результату у больших проектов. Зная этот недостаток ни один зравомыслящий лидер не примет решение использовать сложные шаблоны и сключения для больших проектов. Лидеры проекта gcc - здравомыслящие.

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

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

Ivan_qrt ★★★★★ ()
Ответ на: RIP, my dear GCC от rtvd

Любителям C++ посвящается вопрос:

Что будет в этой программе

1) и 2) не скомпилятся. В 3) и 4) выведутся длинна строки и что-то рандомное (по стандарту не определено)

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

>> 1. X это true

2. X это false

не скомпилируется

3. X это «true»
4. X это «false»

выведет 4/5 и мусорное значение

А вот и нет :-)

Попробуй для начала вариант №2 и просветлись по-полной.

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

Удивительно. У Вас, наверное, другой g++ :)

Проверяю вариант #2:

rtvd@rtvd-desktop:~$ g++ -o test test.cc
rtvd@rtvd-desktop:~$ ./test
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct NULL not valid
Aborted

Так что

а) компилируется, и даже warning не говорить
б) валится

Чем собирал у себя?

У меня g++ v 4.4.1

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

Причем то, что наблюдаю я, не является багом g++. Это особенность C++.

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

> У меня скомпилилось и при запуске выдало std::logic_error

А понимаете почему? :-)

Это я к тому, что есть причина, почему разработчики GCC столь осторожны с разрешением C++.

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

> А понимаете почему? :-)

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

Все же хотелось бы услышать квалицифированное объяснение

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

> Удивительно. У Вас, наверное, другой g++ :)

VC, gcc - да, вариант с false съел, т.к. очевидно привел его к NULL

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

Все же хотелось бы услышать квалицифированное объяснение


Так и есть.

bool -> int ( false -> 0 )

int -> void * ( 0 -> NULL )

void * -> char * ( NULL -> NULL )

char * -> std::string ( NULL -> bah )

Примерно так. Впрочем, я в C++ не специалист. :-)

--

Варианты 3 и 4 тоже радуют. Да, можно компилять с -Wall. Но зачем по-умолчанию GCC даже warning не выдает? И имеем радость наблюдать следующее:

$ g++ -o test test.cc
$ ./test
4
159

Лепота...

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

Ну на 3 и 4 eclipse CDT например ругается, что функция должна что-то возвратить.

А по поводу 2, ну если взять к примеру

#include"string.h"

void main (void){

strlen(0);

return 0;

}

то получаем тот же молчок

beaver@gentoo /home/beaver/1 $ gcc 1.c

beaver@gentoo /home/beaver/1 $

однако

beaver@gentoo /home/beaver/1 $ gcc 1.c -Wall

1.c: In function ‘main’:

1.c:3: warning: null argument where non-null required (argument 1)

1.c:3: warning: null argument where non-null required (argument 1)

1.c:3: warning: statement with no effect

beaver@gentoo /home/beaver/1 $

тогда как плюсы об этом не предупреждают

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

Да, это - похожий случай. Просто в C++ косяков больше.

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

> warning: null argument where non-null required

тогда как плюсы об этом не предупреждают


это уже из разряда статического анализа кода - проверять «хочет» ли функция получать NULL или нет, вероятно gcc либо имеет набор правил либо делает такой анализ

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