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

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

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

lester ★★★★ ()

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

Sylvia ★★★★★ ()

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

Kakerlak ()

Здравый смысл, он как Маугли - всех достанет. Правда, некоторых - довольно поздно.

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

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

переходи на llvm, хотя... он тоже на С++, видимо авторы компиляторов совсем ничего не понимают в программировании

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

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

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

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

>Мне еще думается, что это отчасти из-за того, что в последнее время мало толковых программистов на С появляется

Согласен. Но они пошли на это не ради привлечения большего числа людей. gcc - монополист (в *nix системах) и люди все равно будут пользоваться им все зависимости от желания, так что привлекать никого не надо. Они пошли на это из-за того что сами разработчики gcc любят модное ооп, а программисты на С среди них вырождаются. Поэтому и gcc уже слинкован , начиная с версии 4.4 с библиотекой libstdc++

>все же хотят модное ООП

Да еще и модные питоны, валы ...

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

>решение разумно и отчасти вытекает из того, что GCC уже слинкован , начиная с версии 4.4 с библиотекой libstdc++
линковать gcc с libstdc++ было не разумно, а сейчас уже да...на фоне всего этого, конечно разумно.

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

Дело не в том, что на С++. Печально то, что gcc - огромный проект, над которым работают _много_ людей. Сразу полностью перейти на С++ будет невозможно. А смесь С и С++ - ну ты понял.

З.Ы. Я работал над одним проектом. Сначала написал его на С. Потом понадобился С++. Это адская смесь.

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

Ради прикола. Интересно было бы отметить общее количество багов сейчас и после включения С++.

Kakerlak ()

Поздняк метаться. Clang им уже не догнать.

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

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

Плюсы - это модное ООП? В чистых Сях ООП моднее имхо.

yoghurt ★★★★★ ()

Это начало конца.

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

> Поздняк метаться. Clang им уже не догнать.

Согласен, по отставанию _это_ ничто не может догнать.

А по количеству косяков ваш Clang не дотягивает даже до жабы. Слабаки :)

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

> Сначала написал его на С. Потом понадобился С++. Это адская смесь.

что именно у тебя не получилось?

lester ★★★★ ()

О! Еще и компиляторы тормозить начнут. А уж каким будет продукт компилирования - даже и подумать страшно.

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

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

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

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

> что именно у тебя не получилось?

Плавный и бескосячный переход :)

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

> А что не так в исключениях?

медленные - для компилятора это точно критично

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

> ...при разработке GCC (GNU Compiler Collection, а не сам компилятор языка C).

Так что компиляция сишного кода, думаю, не сильно пострадает. А C++-ный компилятор и так работал не очень-то и быстро.

Решение логичное, IMO.

cruxish ★★★★ ()

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

исключения всё-таки удобны для структурирования кода, а остальное и действительно излишне.

boo32 ()

> Использование .... будет запрещено. Это мотивировано тем, что это будет сложно для программистов на C

И какой тогда смысл использовать C++ ?

А ещё можно запретить возможности С, которых нет в ассемблере, т.к. это будет сложно для программистов asm-a

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

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

A-234 ★★★★★ ()
Ответ на: комментарий от vadiml

> И какой тогда смысл использовать C++ ?

как минимум stl, ну и ООП судя по всему

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

> О! Еще и компиляторы тормозить начнут. А уж каким будет продукт компилирования - даже и подумать страшно.

Да ну, ерунда какая. При грамотном подходе код на С++ может быть быстрее, чем на С за счет того, что некоторые вещи можно вынести в compile-time. Ну и объем кода сокращается, исключаются целые классы ошибок и т. д. Но это всё при *грамотном* подходе.

В общем, предлагаю начать плюсосрач.

Relan ★★★★★ ()

печальная новость. gcc rip.

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

На Си на самом деле можно те же приемы использовать, что и на плюсах. Компилятор все-таки не какое-то пользовательское приложение. Не зря же поговорка - 99% людей оптимизируют код хуже компилятора, а оставшиеся 1% пишут компиляторы. Эту поговорку в основном используют те, кто пишут на языках высокого уровня.

hibou ★★★★★ ()
Ответ на: комментарий от A-234

> Исключения штука удобная но тормозная.

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

Relan ★★★★★ ()

алсо, предлагаю перевести gcc на .net или java, чтоб совсем ынтерпрайзно и глобально-надёжно было.

anonymous ()

Ну что, последователи Линуса, С++ ненавистники... выкусили? :)...

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

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

в чем именно они надежней?

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

>> А что не так в исключениях?

> медленные - для компилятора это точно критично


Неуд. Можешь садиться.

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

А причина запрета исключений в GCC совсем другая: исключения требуют написания exception-safe кода, каковым унаследованный код на Си не является.

Manhunt ★★★★★ ()

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

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

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

> в чем именно они надежней?

Не обработаешь исключени - программа упадет. Не обработаешь код ошибки - сглючит.

tailgunner ★★★★★ ()

а какие были причины использовать С++? чего не хватало в Си? странная новость.

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

>Плюсы - это модное ООП? В чистых Сях ООП моднее имхо.

просто у некоторых при словах «ООП в Сях» случается сегфолт в голове, вот и лезут в С++, где ООП «проще», а не тут то было.

mono ★★★★★ ()

>> GNU Compiler Collection, а не сам компилятор языка C

уфф ...

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

> Неуд. Можешь садиться.
> Пока ты не выполнишь throw, никакого замедления не будет.


сколько же ламерья в топике... ты выхлоп в ассемблере посмотри( если осилишь )

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

> Не обработаешь исключени - программа упадет.
> Не обработаешь код ошибки - сглючит.


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

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

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

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

> Компилятор все-таки не какое-то пользовательское приложение.


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

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

>сколько же ламерья в топике...

да.. что же мы без тебя, лестер, делали.

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

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

Портабельность. Впрочем это старый предрассудок.

rudchenkos ()

здесь будет не меньше 30 страниц

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

>> Пока ты не выполнишь throw, никакого замедления не будет.
> ты выхлоп в ассемблере посмотри( если осилишь )


Я смотрел. А ты - нет. Верно?

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

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

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

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

> Я смотрел. А ты - нет. Верно?

без исключений - запись результата и проверка это всего две инструкции: movl + cmpl

	.file	"2.cpp"
	.text
.globl __Z1Cv
	.def	__Z1Cv;	.scl	2;	.type	32;	.endef
__Z1Cv:
	pushl	%ebp
	movl	%esp, %ebp
	movl	$2, %eax
	leave
	ret
.globl __Z1Av
	.def	__Z1Av;	.scl	2;	.type	32;	.endef
__Z1Av:
	pushl	%ebp
	movl	%esp, %ebp
	movl	$1, %eax
	leave
	ret
.globl __Z1Bv
	.def	__Z1Bv;	.scl	2;	.type	32;	.endef
__Z1Bv:
	pushl	%ebp
	movl	%esp, %ebp
	call	__Z1Cv
	leave
	ret
	.def	___main;	.scl	2;	.type	32;	.endef
.globl _main
	.def	_main;	.scl	2;	.type	32;	.endef
_main:
	pushl	%ebp
	movl	%esp, %ebp
	andl	$-16, %esp
	call	___main
	call	__Z1Av
	cmpl	$1, %eax
	call	__Z1Bv
	cmpl	$2, %eax
	movl	$0, %eax
	leave
	ret 

с исключениями:

	.file	"1.cpp"
	.text
.globl __Z1Cv
	.def	__Z1Cv;	.scl	2;	.type	32;	.endef
__Z1Cv:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$24, %esp
	movl	$4, (%esp)
	call	___cxa_allocate_exception
	movl	%eax, %edx
	movl	$2, (%edx)
	movl	$0, 8(%esp)
	movl	$__ZTIi, 4(%esp)
	movl	%eax, (%esp)
	call	___cxa_throw
.globl __Z1Av
	.def	__Z1Av;	.scl	2;	.type	32;	.endef
__Z1Av:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$24, %esp
	movl	$4, (%esp)
	call	___cxa_allocate_exception
	movl	%eax, %edx
	movl	$1, (%edx)
	movl	$0, 8(%esp)
	movl	$__ZTIi, 4(%esp)
	movl	%eax, (%esp)
	call	___cxa_throw
	.def	__Unwind_SjLj_Resume;	.scl	2;	.type	32;	.endef
	.def	___gxx_personality_sj0;	.scl	2;	.type	32;	.endef
	.def	__Unwind_SjLj_Register;	.scl	2;	.type	32;	.endef
	.def	__Unwind_SjLj_Unregister;	.scl	2;	.type	32;	.endef
.globl __Z1Bv
	.def	__Z1Bv;	.scl	2;	.type	32;	.endef
__Z1Bv:
	pushl	%ebp
	movl	%esp, %ebp
	pushl	%edi
	pushl	%esi
	pushl	%ebx
	subl	$108, %esp
	movl	$___gxx_personality_sj0, -68(%ebp)
	movl	$LLSDA8, -64(%ebp)
	leal	-60(%ebp), %eax
	leal	-24(%ebp), %edx
	movl	%edx, (%eax)
	movl	$L12, %edx
	movl	%edx, 4(%eax)
	movl	%esp, 8(%eax)
	leal	-92(%ebp), %eax
	movl	%eax, (%esp)
	call	__Unwind_SjLj_Register
	movl	$2, -88(%ebp)
	call	__Z1Cv
	jmp	L10
L11:
	cmpl	$2, %edx
	jne	L13
L7:
	movl	%eax, (%esp)
	call	___cxa_begin_catch
	movl	%eax, -28(%ebp)
	movl	$0, -88(%ebp)
	call	___cxa_end_catch
	jmp	L10
L13:
L8:
	movl	%eax, (%esp)
	call	___cxa_begin_catch
	movl	$4, (%esp)
	call	___cxa_allocate_exception
	movl	%eax, %edx
	movl	$2, (%edx)
	movl	$0, 8(%esp)
	movl	$__ZTIi, 4(%esp)
	movl	%eax, (%esp)
	movl	$1, -88(%ebp)
	call	___cxa_throw
L12:
	leal	24(%ebp), %ebp
	movl	-88(%ebp), %ecx
	movl	-84(%ebp), %eax
	movl	-80(%ebp), %edx
	cmpl	$1, %ecx
	je	L11
L9:
	movl	%edx, -96(%ebp)
	movl	%eax, -100(%ebp)
	movl	$0, -88(%ebp)
	call	___cxa_end_catch
	movl	-100(%ebp), %eax
	movl	-96(%ebp), %edx
	movl	%eax, (%esp)
	movl	$-1, -88(%ebp)
	call	__Unwind_SjLj_Resume
L5:
L10:
	leal	-92(%ebp), %eax
	movl	%eax, (%esp)
	call	__Unwind_SjLj_Unregister
	addl	$108, %esp
	popl	%ebx
	popl	%esi
	popl	%edi
	leave
	ret
	.section	.gcc_except_table,"dr"
	.align 4
LLSDA8:
	.byte	0xff
	.byte	0x0
	.uleb128 LLSDATT8-LLSDATTD8
LLSDATTD8:
	.byte	0x1
	.uleb128 LLSDACSE8-LLSDACSB8
LLSDACSB8:
	.uleb128 0x0
	.uleb128 0x0
	.uleb128 0x1
	.uleb128 0x3
LLSDACSE8:
	.byte	0x1
	.byte	0x0
	.byte	0x2
	.byte	0x7d
	.align 4
	.long	__ZTISt9exception
	.long	0
LLSDATT8:
	.text
	.def	___main;	.scl	2;	.type	32;	.endef
.globl _main
	.def	_main;	.scl	2;	.type	32;	.endef
_main:
	pushl	%ebp
	movl	%esp, %ebp
	andl	$-16, %esp
	pushl	%edi
	pushl	%esi
	pushl	%ebx
	subl	$100, %esp
	movl	$___gxx_personality_sj0, 52(%esp)
	movl	$LLSDA9, 56(%esp)
	leal	60(%esp), %eax
	movl	%ebp, (%eax)
	movl	$L24, %edx
	movl	%edx, 4(%eax)
	movl	%esp, 8(%eax)
	leal	28(%esp), %eax
	movl	%eax, (%esp)
	call	__Unwind_SjLj_Register
	call	___main
	movl	$2, 32(%esp)
	call	__Z1Av
	call	__Z1Bv
	jmp	L15
L23:
	cmpl	$2, %edx
	jne	L25
L16:
	movl	%eax, (%esp)
	call	___cxa_begin_catch
	movl	%eax, 88(%esp)
	movl	$0, 32(%esp)
	call	___cxa_end_catch
	jmp	L15
L25:
L17:
	movl	%eax, (%esp)
	call	___cxa_begin_catch
	movl	$0, 32(%esp)
	call	___cxa_end_catch
L15:
	movl	$1, 32(%esp)
	call	__Z1Bv
	call	__Z1Av
	jmp	L18
L24:
	movl	32(%esp), %ecx
	movl	36(%esp), %eax
	movl	40(%esp), %edx
	cmpl	$1, %ecx
	je	L23
	cmpl	$2, %edx
	jne	L26
L19:
	movl	%eax, (%esp)
	call	___cxa_begin_catch
	movl	%eax, 92(%esp)
	movl	$0, 32(%esp)
	call	___cxa_end_catch
	jmp	L18
L26:
L20:
	movl	%eax, (%esp)
	call	___cxa_begin_catch
	movl	$0, 32(%esp)
	call	___cxa_end_catch
L18:
	movl	$0, %eax
	movl	%eax, 24(%esp)
L14:
	leal	28(%esp), %eax
	movl	%eax, (%esp)
	call	__Unwind_SjLj_Unregister
	movl	24(%esp), %eax
	addl	$100, %esp
	popl	%ebx
	popl	%esi
	popl	%edi
	leave
	ret
	.section	.gcc_except_table,"dr"
	.align 4
LLSDA9:
	.byte	0xff
	.byte	0x0
	.uleb128 LLSDATT9-LLSDATTD9
LLSDATTD9:
	.byte	0x1
	.uleb128 LLSDACSE9-LLSDACSB9
LLSDACSB9:
	.uleb128 0x0
	.uleb128 0x3
	.uleb128 0x1
	.uleb128 0x3
LLSDACSE9:
	.byte	0x1
	.byte	0x0
	.byte	0x2
	.byte	0x7d
	.align 4
	.long	__ZTISt9exception
	.long	0
LLSDATT9:
	.text
.globl __ZTISt9exception
	.section	.rdata$_ZTISt9exception,"dr"
	.linkonce same_size
	.align 4
__ZTISt9exception:
	.long	__ZTVN10__cxxabiv117__class_type_infoE+8
	.long	__ZTSSt9exception
.globl __ZTSSt9exception
	.section	.rdata$_ZTSSt9exception,"dr"
	.linkonce same_size
__ZTSSt9exception:
	.ascii "St9exception\0"
	.def	___cxa_allocate_exception;	.scl	2;	.type	32;	.endef
	.def	___cxa_throw;	.scl	2;	.type	32;	.endef
	.def	___cxa_begin_catch;	.scl	2;	.type	32;	.endef
	.def	___cxa_end_catch;	.scl	2;	.type	32;	.endef 
lester ★★★★ ()
Ответ на: комментарий от Manhunt

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

int C( void )
{
	return 2;
}

int A( void )
{
	return 1;
}

int B( void )
{
	return C();
}


int main() 
{ 
	if( A() == 1 ) {}
	if( B() == 2 ) {}

   return 0; 
} 
#include <exception>

void C( void )
{
	throw 2;
}

void A( void )
{
	throw 1;
}

void B( void )
{
	try
	{
		C();
	}
	catch(std::exception& e)
	{
	}
	catch(...)
	{
		throw 2;
	}
}


int main() 
{ 

	try
	{
		A();
	}
	catch(std::exception& e)
	{
	}
	catch(...)
	{
	}

	try
	{
		B();
	}
	catch(std::exception& e)
	{
	}
	catch(...)
	{
	}

   return 0; 
} 
lester ★★★★ ()
Ответ на: комментарий от Relan

> Ну и объем кода сокращается, исключаются целые классы ошибок и т. д.

И т.д. - появляются целые классы новых ошибок, которых раньше просто не могло быть.

> Но это всё при *грамотном* подходе.

И это при условии грамотного подхода. При неграмотном и старые классы ошибок никуда не деваются.

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