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 ()
Последнее исправление: Silent (всего исправлений: 2)
Ответ на: комментарий от 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

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

anonymous
()
Ответ на: комментарий от 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

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
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.