LINUX.ORG.RU

Попытка реинтеграции компилятора D в состав GCC

 , ,


2

6

Как можно заключить из сообщений в рассылке разработчиков gcc, к версии gcc 4.8 будет предпринята попытка официально ввести в состав gcc gdc — свободную реализацию компилятора языка D (digitalmars D).

D позиционируется как «системный язык программирования высокого уровня» и предоставляет как высокоуровневые возможности, включая присущие динамическим языкам, так и позволяет при необходимости задействовать характерные для системного программирования низкоуровневые особенности, включая ручное управление памятью. В известной степени D можно считать наследником C++, избавленным от неоднозначностей.

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

D не накладывает жёстких парадигменных ограничений и позволяет записывать код в обобщённом, объектно-ориентированном, функциональном и процедурном стилях, а так же их комбинации. Штатно предоставляются полные средства интроспекции. Дополнительно компилятор несёт в себе нечто вроде интерпретатора языка, позволяющего динамически добавлять/изменять методы во время исполнения.

Имеются средства прямого вызова функций, реализованных на языках C и C++.

В целом, D представляется интересным для программирующих пользователей, нуждающихся в современных выразительных средствах, но не имеющих возможности изучать все особые случаи C++.

Свободно доступен референсный компилятор dmd, однако он предназначен, скорее, для исследовательских целей. Появление штатного фронтенда D в наборе gcc позволяет надеяться на переход от чисто экспериментального применения этого интересного и мощного языка к широкому внедрению.

>>> Подробности



Проверено: Shaman007 ()

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

Забавно: reference implementation, но годится для исследовательских целей.

Ну там еще бэкенд под какой-то некошерной лицензией, так что пущай лучше будет gdc

V_L_A_D ★★ ()
Ответ на: комментарий от I-Love-Microsoft

ИМХО, то было отдельное поделие, которое не поставлялось вместе с gcc. Чтобы установить этот компилятор раньше, нужно было патчить, настаривать, править конфиги gcc и т.п., сейчас gdc будет работать «из каробки».

sched ()

Вообще, по теме, хочу сказать. За С++ я с 91г, изучил справочник Страуструпа до дыр, был в те времена просто в восторге. На практике, планируя что-то большое, часто упирался, что когда классов уже за несколько десятков, становится всё очень сложно, и тут вдруг, новое требование, от которого требуется переделать половину структуры, соот-но все интерфейсы, рефакторинг и пр. Переход к динамическим языкам подобные вещи часто заметно упрощает. Да, порой просто где-то костыльно допишется «если передали _ещё_один_параметр_, то...», но гибкость программы повышается, хотя и повышается неочевидное количество возможных ошибок, привнесённых такими костылями. Тут, как я вижу, проблема «переписать 15 тыщ строк кода под новые интерфейсы» vs «сделать пару костылей, постараться не внести побочных эффектов, учесть все варианты». Экономически, часто, целесообразнее второе, несмотря на идеологические недостатки.

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

Миксины. Насколько я понимаю. это фича D 1.0, в D 2.0 вместо них предполагается использовать CTFE и шаблоны.

Миксины появились уже после выхода D 1.000, незадолго до объявления о начале работ над D2.

Ну и CTFE нужны для того, чтобы в compile-time склеить строку, которую затем помещают в mixin (AFAIK). Так что там не столько макросы, сколько работа по типу фокусов с eval или object_eval в Ruby.

eao197 ★★★★★ ()

Я при изучении этого языка столкнулся со следующими проблемами:

1. Сложность создания заголовочных файлов, которые объявляют классы. Строго говоря, такая опция официально не поддерживается, а .di файлы, которые призваны включать только интерфейс, включают также и весь код.

2. Как следствие, сложность написания разделяемых библиотек, которые экспортируют не функции (при экспорте функций всё работает как в Си). Сторого говоря под linux это возможно, но больше напоминает хак, чем поддерживаемую возможность. Под windows трюк с объявлением класса и его методов без кода компилируется/линкуется, но валится в runtime. При генерировании бинарика вся стандартная библиотека и runtime включаются в исполняемый файл, имхо, из-за этих проблем.

3. Компилятор dmd под windows генерирует объектные файлы в формате OMF. Поэтому, линковать что-то с D можно только в этом формате (как следствие, С, С++ нужно компилировать dmc).

4. Конструкция foreach основывается на методах empty(), popFront() и т.д. таким образом, что провести итерацию по const-объекту затруднительно.

5. Язык не стандартизирован.

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

7. Зачем-то убрали такую вещь как аллокаторы и деаллокаторы классов (http://dlang.org/class.html#allocators). Динамические массивы и слайсы не работают без GC. Хотя декларируется, что язык поддерживает ручное управление памятью, но из-за этих проблем такое управление едва ли нужно. Кроме этого, декларируется, что в целях эффективности можно отключить GC, но тогда некоторые части языка не будут работать. Из-за того, что эти части используются повсеместно, часть стандартной библиотеки не будет работать. Короче говоря, в случае выключения GC непросто определить, какая часть кода будет работать, и что можно использовать и что нет.

8. Разработчики так и не договорились насчёт атрибутов.

9. Отсутствует отладчик для D, приходится использовать сишные.

10. Бардак в стандартной библиотеке. С одной стороны, включены такие вещи, как std.cpuid, std.windows.windows. Так же включены std.zlib, std.net.curl, etc.c.zlib, который кстати так же находится в etc.c.curl. Часть стандартной библиотеки находятся в состоянии рефакторинга или редизайна, т. е. при использовании таких модулей нужно понимать, что в будущих версиях интерфейс наверняка изменится.

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

О чём это говорит? PHP sucks, Perl rulez? ;)

Скорее нужно поднимать вопрос об опыте работы в других языках :)

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

Ну и CTFE нужны для того, чтобы в compile-time склеить строку, которую затем помещают в mixin (AFAIK)

Я не слежу за D, но на CTFE там даже рейтрейсер написали %) Так что CTFE пригоден для гораздо большего, чем склейка строк.

Так что там не столько макросы, сколько работа по типу фокусов с eval или object_eval в Ruby.

Про Руби ничего не знаю, но вот что имеет сказать о mixin'ах Александреску:

«It is possible that a more general AST macro facility will replace mixin tenplates in a future revision of language».

Так что это именно макросы.

«You may to think twice before reaching this particular tool in your toolbox».

Но не доведены до ума и опасны в использовании.

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

А что perl разве хорошо работает с десятками классов? Вроде ОО - это его самое слабое место?

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

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

Экономически, часто, целесообразнее второе, несмотря на идеологические недостатки.

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

На большом и/ли длитетельном проекте статический компилятор всегда тебе экономически спасет жизнь.

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

Конструкция foreach основывается на методах empty(), popFront() и т.д. таким образом, что провести итерацию по const-объекту затруднительно.

Э-э-э... empty/popFront - это методы не контейнера, а range (это такие более правильные итераторы). Зачем самим итераторам быть константными?!

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

Про Руби ничего не знаю, но вот что имеет сказать о mixin'ах Александреску:

«It is possible that a more general AST macro facility will replace mixin tenplates in a future revision of language»

Вообще-то, string mixins и mixin templates - это совершенно разные вещи, объединяет которые лишь одно - они относятся к метапрограммированию.

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

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

D не щупал, но C всё-таки гениален и его не закопать, он вечно живой в ядрах ОС.

sv75 ★★★★★ ()

Прочёл срэд

Раз наличествует шквал критики лоровских экспертов, значит, D наверняка интересный, не гиканутый язык, которым есть смысл воспользоваться в самом скором времени.

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

Еще лет 10-20 и будет такой же живой как Форт.

Надеетесь, что принципы построения внезапно ОС сменяться, и в коде шедулера заработает GC?

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

Надеетесь, что принципы построения внезапно ОС сменяться, и в коде шедулера заработает GC?

Нет, но за 20 лет наконец сделают BitC или что-то подобное.

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

Если есть функции как first class citizen, то не очевидно, во что это компилируется. Параноики не согласятся.

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

Ты можешь смеяться, но VisualWorks переименовал... Каюсь, первый раз я не полностью повторил твой код, потому что VW на него ругался. Сейчас ввел и, о чудо, метод был переименован, хотя вроде бы не должен был :)

puperMethod
	| oc c | 
	oc addAllPuperSuper: c.
	^oc
dave ★★★★★ ()
Ответ на: комментарий от sv75

Если есть функции как first class citizen, то не очевидно, во что это компилируется. Параноики не согласятся.

Ты путаешь параноиков и маразматиков.

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

Я надеюсь что появится такой же простой, как Си ЯП, но с изначальной поддержкой современных тенденций (что-то типа ALGOL)

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

Еще лет 10-20 и будет такой же живой как Форт.

Лет через 10-20 каждый сопроцессор вполне может быть реализацией Форта.

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

Всё-таки есть что-то тёплое и ламповое в сооружении closure или vmt при помощи костылей... или как минимум что-то методически верное, чтобы понять, в чём счастье.

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

Я думаю, что 6 типов смартпойнтеров в Бусте - это уже гикануто.

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

У меня есть ощущение, что из трёх моментов «простой (в т.ч. и писателям компилятора), современный (и нестареющий), быстрый» выбрать можно только два из трёх...

C# вон каждый год-два устаревает радикально, с выходом новой.

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

Типа лучше, правда Антонеску и туда зашёл.

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

D такое же УГ как C++ или лучше?

Пока ещё нет, ведь C++ уже сколько лет существует.

Но лет эдак через 5 станет таким что создание альтернативного компилятора будет равносильно созданию Java HotSpot. Только кто этим заниматься будет..

tp_for_my_bunghole ()
Ответ на: Прочёл срэд от malbolge

значит, D наверняка интересный, не гиканутый язык, которым есть смысл воспользоваться в самом скором времени
malbolge * (03.07.2012 20:52:24)

D наверняка интересный, не гиканутый язык
malbolge * (...)

В фортунки.

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

Ну вот конкретно в питоне наличие статической типизации не помешало бы, кстати

Это будет уже не Питон тогда. В динамической типизации — вся соль питона — ему не нужны дженерики и всякие шаблоны благодаря им.

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

А ведь еще тогда (3 года назад) казалось, что еще чуть-чуть и язык стабилизируется, появятся инструменты разработки и т.д.

Ни одна организация не будет вкладывать ресурсы в разработку с использованием недопиленного инструмента. В результате все сидят ждут, когда же оно стабилизируется и периодически всплывают аргументы, что «ни одного серьезного проекта на D». Ну кресты тоже не сразу строились и первые версии «C++ компилятора» вообще были в виде препроцессора. Посмотрим, что будет дальше, но такими темпами оно еще лет 5 точно не стабилизируется.

m0rph ★★★★★ ()

И как это гуглу удалось так быстро (по сравнению с D) всунуть go в gcc?

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