11 октября 2012 в 17:59

Разрушая распространённые мифы о D

Оригинальный текст: semitwist.com/articles/article/view/dispelling-common-d-myths
Reddit: www.reddit.com/r/programming/comments/118y4m/dispelling_common_d_myths/

Вступление


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

Все эти заблуждения вполне объяснимы. Многие связаны с проблемами, которые играли важную роль в прошлом, так что не удивительно, что эти устаревшие представления продолжают существовать. Мне кажется, что это как раз те области, которые сообщество D должно как можно лучше объяснить остальным программистам. Вот эти темы:

  • Для D есть IDE
  • DSource угасает, но проекты на D активны как никогда ранее
  • Разделения на D1 и D2 больше нет
  • Phobos — стандартная библиотека? А как же Tango?
  • D — open source
  • D позволяет ручное управление памятью
  • Статическая типизация НЕ означает непродуктивность


Для D есть IDE


Были времена, когда едва ли существовали IDE с поддержкой D чуть больше чем банальная подсветка синтаксиса. Но теперь это не так. Если вам по душе полноценные среды разработки, есть три основных варианта, каждый из которых активно поддерживается:


DSource угасает, но проекты на D активны как никогда ранее


С регулярностью в пару месяцев возникают вопросы такого рода: «D мёртв? Я зашёл на DSource и все проекты выглядели устаревшими и неподдерживаемыми, а форумы пусты. Складывается ощущение, что D умирает.»

DSource был де-факто местом для хостинга проектов на D. Обратите внимание — БЫЛ. В настоящее время большинство активных проектов переехало на Github и Bitbucket. На самом деле, даже репозитории с референсным компилятором D и стандартной библиотекой расположены на Github вот уже больше года. И за это время темп разработки значительно ускорился, а не наоборот.

Были некоторые поползновения обновить DSource для того, чтобы было проще найти активные проекты среди умерших ( не стоит забывать, что любой хостинг open-source проектов обречён со временем собирать множество заброешнных ). Но в связи с огромной популярностью, которую получили Github и Bitbucket, ценность усилий в этом направлении сочли незначительной.

Хотя, должен признаться, меня огорчает говорить такое про DSource. Я всегда ценил этот сайт и в своё время его существование было чертовски нужным и полезным для инфраструктуры D1, задолго до того как Github и Bitbucket стали обыденностью для почти каждого open-source программиста. Сайт, сетевой канал и сам хостинг были безвозмездно пожертвованы для сообщества D ( и таковы до сих пор! ), так что мне неприятно говорить о DSource в духе панегирика. Но в любом случае, хотя DSource почти не используются в современной инфраструктуре D, сам язык не только очень и очень жив, он развивается прямо на глазах.

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

Разделения на D1 и D2 больше нет


D2 — это текущее положении дел. D2 уже считается стабильной веткой, D1 — пережиток прошлого. Забудьте про D1, можете даже не тыкать палочкой, оно мертво.

И когда я говорю «мертво» я не имею в виду тот же вид смерти, что можно представить по аналогии с Python 2. Я имею в виду, что практически никто не больше использует D1. Все уже на D2, даже запоздавшие. D1 достаточно мало используется, что его официальная поддержка прекращается в конце этого года ( как было объявлено год назад ). Никого не волнует D1. Всё, точка.

Есть только D2.

( Примечание переводчика: автор немного погорячился тут с «мертво», скорее «никто не использует D1 для новых проектов, это чистый legacy» )

Phobos — стандартная библиотека? А как же Tango?


Возможно вы слышали о противостоянии Phobos vs Tango. Оглядываясь в прошлое, это была несомненная ошибка D, но проблема была идентифицирована и исправлена. Вкратце суть: Phobos является стандартной библиотекой D, точка. Tango теперь является дополнительной и опциональной, но полностью Phobos-совместимой библиотекой. Как-то так.

Но так было не всегда. Немножко истории для тех, кому интересно:

Давным-давно, во времена молодости D1, задолго до того как Андрей Александреску присоединился к команде, состояние стандартной библиотеки Phobos было далеко не лучшим. Она разрабатывалась от и до одним единственным человеком ( Уолтером Брайтом ), который, конечно же, будучи основным разработчиком языка, был слишком занят работой над языком и компилятором. И по ряду причин она тогда не была полноценным open-source.

Поэтому группа талантливых разработчиков собралась и решила исправить эту проблему, создав полноценную стандартную библиотеку. Её назвали Tango и она была настолько лучше незаконченной Phobos, что стала стандартом де-факто.

К сожалению, для нормальной работы Tango пришлось заменить некоторые низкоуровневые части Phobos, связанные со средой времени выполнения. Библиотеки стали несовместимыми — не было никакого способа использовать обе одновременно. Это, само собой, стало настоящим кошмаром для пиара D.

Тем временем, Phobos стал полность open-source, Андрей Александреску взял на себя руководство его разработкой и понемногу Phobos становился краше и законечнней. В некоторых местах он был чертовски хорош, но это не помогало ключевой проблеме несовместимости Phobos и Tango. Но к счастью, сообщество разработчиков D услышало многочисленные жалобы насчёт двух стандартных библиотек и сосредоточилось на решении проблемы.

На тот момент D2 развивался в качестве основной unstable ветки, в то время как D1 стал stable веткой, в которой запрещены изменения, ломающие обратную совместимость. И для D2 вся функциональность, что создавала несовместимость между Phobos и Tango была переработана и вынесена в отдельную сущность Druntime. Так что тперь и Phobos, и Tango используют Druntime и являются полностью совместимыми. Никакого конфликта больше не существует.

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

Что может заставить вас обратится к Tango? Те же причины, что и к любой дополнительной библиотеке: если вам больше нравится её дизайн, как вариант. Tango стилистически намного более похоже на Java и может понравиться перешедшим из этого языка. Или вам потребовалось что-то из Tango, чего в Phobos банально нет. Например, в Tango реализован самый быстрый в мире XML парсер. В то же время модуль XML из Phobos входит в число вещей, которые ой как надо бы взять и переписать с нуля. ( Не беспокойтесь, остальная часть Phobos просто великолепна. )

D — open source


Существует 3 основных компилятора для D:
  • DMD: референсный компилятор
  • GDC: использует GCC бэкэнд и находится в процессе включения в основную поставку GCC
  • LDC: использует LLVM


GDC и LDC — самый настоящий open-source, без всяких но, и даже включены в соответствующие разделы репозиториев некоторых дистрибутивов Linux. Стандартная библиотека и среда исполнения, Phobos и Druntime — лицензированы под Boost-лицензией, одобренной Open Source Initiative.

Все исходники DMD доступны на Github. Front-end, который используется так же и GDC c LDC, имеет одобренную OSI Artistic лицензию и так же GPL лицензию.

Единственная вещь, которая формально не является open-source — DMD back-end. Причина — используется вещи, лицензированные в своё время у Symantec и Уолтер не может просто так сменить лицензию. Но исходники публично доступны и pull request'ам всегда рады. Вас беспокоит распространение? Не стоит: просто попросите самого Уолтера. Лицензия обязывает его требовать спрашивать его разрешения ( Прим. переводчика: рад совету, как этот копирастический казус сформулировать по-русски нормально ), но это чисто техническая формальность. Попросите у него, и тут же получите разрешение. Не известно ещё ни одного случая отказа. И да, не забвайте, это касается только DMD, точнее back-end DMD. Всё остальное — open-source без всяких «но», включая два полноформатных компилятора, GDC и LDC.

D — open-source. Не всегда был, но вне всяких сомнений таков сейчас.

D позволяет ручное управление памятью


Хотя в D предполагает наличие сборщика мусора по умолчанию, но это отнюдь не означает, что вы не можете управлять им, заменить его или вообще убрать, или использовать ручное управление памятью.

В D есть указатели ( элегантно ограниченные безопасными для памяти доступными операциями в @ safe режиме ) и прямой вызов функций на C. В вашем распоряжении malloc/free и вы можете разместить что угодно в полученной таким образом памяти используя emplace. Или попробуйте стэковые scoped классы. Или счётчики ссылок. Или RAII. Плюс ко всему, сейчас в процессе разработки находится система настраиваемых аллокаторов.

Статическая типизация НЕ означает непродуктивность


D — статически типизированный язык, но это не должно у вас вызывать ассоциации со стилем C++ или Java:
% cat funWithRanges.d
import std.algorithm;
import std.range;
import std.stdio;

void main()
{
	// All done lazily:
	auto squares   = sequence!((a,n) => n^^2)(0);
	auto fibonacci = recurrence!((a,n) => a[n-1] + a[n-2])(1, 1);
	auto fibEven   = fibonacci.filter!(x => x%2 == 0)();

	foreach(v; zip(squares, fibonacci, fibEven).take(6))
		writeln(v[0], "\t", v[1], "\t", v[2]);
}

% rdmd funWithRanges.d
0       1       2
1       1       8
4       2       34
9       3       144
16      5       610
25      8       2584

D не только продуманный и эффективный, но так же безопасный и корректный.

Добавьте ещё разные полезные штуки для параллельных выичслений, простые шаблоны и инструменты метапрограммирования, а так же разные полезности, ставшие уже обыденностью.
+68
24555
118
Volfram 16,9

Комментарии (56)

+3
Volfram, #
Замечание от переводчика: этот пост напомнил мне, что с момента последнего основательного обзора состояния дел в D прошло изрядно времени и все успело поменяться. Предлагаю всем, кто заинтересован, но не имеет времени разобраться в деталях оставлять здесь запросы на интересующие темы по D(2), и, кто знает, быть может эта информация вскоре появиться на Хабре ;)
0
sashkin, #
Меня последние месяцы мучает вопрос, который никак не дойдут руки проверить. Пишем софт под embedded qnx и там toolchain'ы базирующиеся на gcc, но конфиги бэкенда заточены под эту ос (объектники, набор рантайм либ слегка специфичный). Можно как-то прикрутить gdc фронтенд к такому backend-у? Был подобный опыт?
+1
Volfram, #
Можно, но вероятность изменений в коде, склеивающим frontend и backend крайне велика. Сами по себе они не сильно связаны, так так frontend у всех 3х компиляторов D один и тот же. Лучше всего пообщаться на этот счёт с Ian Buclaw, он является на данный момент ведущим мейнтейнером GDC. Дополнительно может потребоваться подправить druntime, в зависимости от того, насколько система posix-compliant.

Конкретно под qnx едва ли кто-то пытался завести, несколько человек неторопливо пилят в сторону Android NDK, можно получить некоторое представление о возникающих проблемах при портировании под новые ОС/железо в этой теме: forum.dlang.org/thread/20120204203109.26c9a80b@jpf-laptop

Общее мнение — ничего неподъемного или сверхдолгого, но засучить рукава и разобраться в исходниках toolchain придётся. Тема достаточно специфическая.
0
PQR, #
Хотел спросить про веб-разработку на D. В комментах уже нашел ссылку на проект vibe.d (http://vibed.org).
Расскажите больше! Это единственный «движок» для веб-проектов на D или есть и другие? Какие-нибудь истории успеха в запуске веб-сайтов написанных на D?
0
Volfram, #
Если интересует именно фреймворк «всё включено», то да, единственный. А так есть, например, ещё и github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff — этот добрый молодец ведёт коммерческую разработку сайтов на D2 уже несколько лет в связке с fastCGI. Выше уже упомянули, что веб-клиент к официальным newsgroup тоже написан на D2.

По vibe.d собираюсь делать отдельный обзор в ближайший месяц-два.
0
build_your_web, #
Хотел бы узнать подробности о druntime.
+1
XimikS, #
Что у D с работой под ARM, и игровыми движками? Интересуют мобильные платформы.
0
Volfram, #
ARM как таковой — не проблема, GDC вполне умеет под него собирать. Проблема в системном окружении, т.к. тот же Anroid не вполне posix-compliant и требуются внимательные изменения в druntime как минимум. Выше уже приводил ссылку на эксперименты со сборкой gdc под Android NDK: forum.dlang.org/thread/20120204203109.26c9a80b@jpf-laptop

Про iOS не знаю ничего.

C мобильными игровыми движками всё проще — ничего не мешает использовать их через C-bindings прямо сейчас кроме того, что runtime базового языка не готов. В целом это одно из тех направлений, где формально со стороны языка/компиляторов почти всё готово для создания инфраструктуры, но нужен кто-то, достаточно заинтересованный, чтобы потратить усилия на изначальное портирование и поиск багов. На данный момент в D community специализирующихся на этом направлении я не знаю. Геймдевелоперы есть, но не под мобильные системы.
0
Robotex, #
А в чем прелесть D? Как как он в сравнении с cpp11 по параметрам быстродействие приложений, потребление ими памяти, скорость и удобство разработки? Возможно на нем разрабатывать кроссплатформенные приложения?
+3
Volfram, #
Это очень обширная тема, даже на хабре уже есть штук 5 статей на тему обзора плюшек D. В один комментарий по-хорошему не уложусь. Попробую совсем бегло.

Быстродействие при сравнении gdc vs gcc — одного порядка, больше зависит от мастерства разработчика, чем от особенностей языка. Память — зависит от того, сколько волностей разрешаете garbage collector. Стартовый overhead выше за счёт druntime, но потребление памяти приложением как таковым полностью зависит от выбранной модели работы с оной. Скорость и удобство разработки — в пользу D на порядок, без преувеличений, просто не сравнимые вещи.

Кроссплатформенность, конечно, возможна, на сейчас как раз идёт бета-тест версии DMD с поддержкой Win64 и COFF формата, после его релиза базовый набор Linux/Windows/Mac 32/64 будет поддержан в полном виде. ARM — через GDC.

Прелести в сравнении с С++ навскидку:
— система шаблонов, изначально спроектированная для массового использования, в отличии от случайной находки С++
— полноценные делегаты и иже с ними
— более мощная система типов за счёт доп. гарантий от компилятора и способов статической интроспекции
— ranges ( дальнейшее развитие итераторов ) как базовое понятие языка и основа дизайна как встроенных массивов, таки и стандартной библиотеки

dlang.org/comparison.html

Один из старых слоганов D ЕМНИП — «C++ done right»
+1
Robotex, #
Qt на него планируется портировать?
0
Volfram, #
bitbucket.org/qtd/repo
Довольно давно не обновлялось, впрочем, не знаю насколько сейчас юзабельно.
Gtkd поддерживается сейчас несколько активнее.
0
pravic, #
> как раз идёт бета-тест версии DMD с поддержкой Win64 и COFF формата
1.1 Что вообще могут на текущий момент генерировать компиляторы (dmd2, ldc, gdc)? В случае последних — всё, что поддерживается бэкэндами? Или же поддерживается только х86? Я имею ввиду именно генерацию кода в объектники.

1.2 Что из вышеперечисленного реально работает? (Тут вопрос уже про полноценную поддержку окружения)

По андроиду — насколько я понял, есть форк gdc, но у них проблемы с druntime over bionic.
0
Volfram, #
1.1 — да, всё что поддерживается бэкэндами

1.2 — помимо x86 мне известно об успешном запуске под ARM/Linux. В теории должно без большой головной боли заводится всё, что поддерживает backend и что достаточно posix-compliant, чтобы на нём с пол пинка собрался druntime.

Про android всё верно понимаете.
0
Mirraz, #
Слышал, что при ручном управлении памятью придётся отказаться от стандартных библиотек.
Невозможность абсолютно полного ручного управления памятью — единственное, что меня отталкивает от D.
+1
Volfram, #
Это не совсем так. Garbage collector и ручное управление памятью прекрасно соседствуют в D бок о бок. Некоторые известные мне проекты используют предаллоцированные пулы памяти управляемые вручную для основной массы данных и garbage collector — для «менеджерских» задач, поддержки делегатов и тому подобных плюшек. Получается довольно практично.

Другое дело, если существование garbage collector для вас вообще непримлемо, даже в качестве скулящего в углу бедного родственника. Тогда да, про phobos придётся забыть, т.к. там может выделяться память, которая начнёт течь. С другой стороны, вся стандартная библиотека С все ещё в полном распоряжении, так что относительно С вы ничего не теряете.

Когда Александреску опубликует спеки по аллокаторам ( он очень серьёзно относится к их дизайну и не хочет ничего показывать, пока не будет наверняка ) ситуация просто превратится из нормальной в великолепную: )
+1
Mirraz, #
А можно поподробней про эти аллокаторы? Почему жизнь с ними станет лучше?
0
Volfram, #
I'm making good progress on an allocator design. If things come together
as I hope, it'll kick some serious ass.

I'm currently looking at four allocation models:

* straight GC, safe (no deallocation)
* GC + the ability to free memory
* malloc/free, unsafe, buyer beware (STL-level safety)
* reference counted (based on either malloc or GC+free)
* region (scoped)

© Alexandrescu этой весной. С тех пор что-то застопорилось, но продолжаем верить :)

Почему станет лучше — а) исчезнет привязка аллокации в phobos на garbage collector, станет возможным использование всей стандартной библиотеки вообще не включая gc в приложение б) это будет означать зелёный свет для добавление продвинутых контейнеров в стандартную библиотеку.
+2
bfDeveloper, #
Ещё одну хорошую IDE забыли — D-IDE
Лично мне нравится больше всех остальных. Простая и умеет почти всё что надо. Интерфейс только странный.
0
Volfram, #
Во-первых, это перевод.
Во-вторых, я подозреваю, что автор оригинального текста упомянул те, над которыми ведется активная работа именно сейчас.

P.S. Хотя, как вижу, у D-IDE тоже совсем недавно были коммиты, это отрадно.
+1
Nekuromento, #
У D-IDE и Mono-D один разработчик и даже единый code-base.
0
Volfram, #
Спасибо, не знал, думал это одна из многочисленных полузаброшеных попыток сделать IDE с нуля.
+2
Radagast, #
Или попробуйте стэковые scoped классы. Или счётчики ссылок. Или RAII.

я не совсем понимаю, где там RAII, когда в Andrei Alexandrescu — The D Programming Language — Addison Wesley 2010 я читаю:
tearing an object down follows a little protocol:

4. At some implementation-dependent point, the system acknowledges that the object's memory may be recycled and invokes its destructor.

так деструктор вызывается сразу при выходе из scope/удалении объекта (как в С++), или когда-нибудь в будущем, когда у сборщика до него дойдут руки (как финализаторы в Java/C#)?
+2
Volfram, #
О, это хороший вопрос и отличное напоминание о том, что стоит бы потереть устаревшую документацию на офф. сайте.

Основной предлагаемый способ RAII шаблон scoped!T: dlang.org/phobos/std_typecons.html#scoped
Создаёт экземпляр класса на стеке, запрещает любое его присваивание, при выходе из scope вызывается деструктор, а состояние объекта вырождается в T.init. Реализовано через структуру с полем аналогичного классу размера, alias this и emplace.

Не вполне RAII по букве, но решает ту же задачу — scope(exit) / scope(success) / scope(failure). Формата:
lock(mutex);
scope(exit) unlock(mutex);
// code here


Когда-то предполагалось использовать для этих целей специальные scope классы, которые имеют специальные правила по аллокации. И спеки ещё можно найти на сайте, и оно ещё работает. Но считается deprecated из-за небезопасного диазайна и оттого не упоминается в TDPL.

По хорошему, надо пройтись по репозиторию с доками офф. сайта и вычистить всё это. Я даже собирался заняться, но это как минимум пара дней нуднейшей вычитки спеков и пока не собрался: )
+1
Radagast, #
спасибо. а если объект не на стеке, а в куче? или data member другого объекта? решение будет таким же?
0
Volfram, #
Тогда согласно приведённой вами цитате из TDPL. Если это управляемая GC куча. Если память была выделена через malloc & Co — то как в plain C, только руками.
0
Radagast, #
просто раз D позиционируется как полноценная замена С++, то я не понимаю, зачем нужно было отказываться от детерминированных деструкторов :(
а есть еще какие-нибудь области С++ (как языка), кроме хитрых шаблонов, в аналоге которых в D придется делать костыли?
+1
Monnoroch, #
Судя по моему опыту, как раз хитрые шаблоны в D сделаны на славу, и это скорее в C++ будут аналоги смотреться костыльно :)
+2
Volfram, #
Модель памяти уровня языка в D сложнее, оттого несколько другие задачи при дизайне. Деструкторы детерменированны, время жизни объекта под контролем сборщика мусора — нет. Деструкторы стэковых объектов ( структуры, например) вызываются при выходе из области видимости гарантированно. Точно так же возможно явно использовать destroy для вызова деструктора, но детерменированно освободить принадлежащую gc память — нет.

Про костыли сказать не могу, т.к. мне это не кажется костылём, но плохо задокументированной частью языка, которая требует переосмысления подхода к дизайну :) Я затрудняюсь придумать хоть одну фичу С++, аналогия которой в D будет выглядеть костыльнее.
А вообще из неожиданностей — у структур не может быть конструктора по умолчанию, const/immutable/shared — транзитивны, глобальные переменные thread-local по умолчанию.

Выпад в сторону шаблонов не понял, т.к. при переходе это скорее «убрать костыли на С++ и написать нормально на D».
+1
Radagast, #
ясно, спасибо.
«костыли» не относились к «шаблонам», просто я неудачно сформулировал =\
0
Nekuromento, #
При использовании Scoped финализатор вызывается сразу по выходу из области видимости, но память не освобождается сразу а освободится когда-нибудь GC.
+1
brainunit, #
Вы можете сравнить сборщик мусора в D со сборщиком мусора в .NET? Поддерживается ли сборка по поколениям, есть ли фоновая сборка? Насколько GC хорош для серверных приложений?
+2
Volfram, #
Легко, сборщик мусора в D — не очень: ) Он основан на Hans Boehm’s C++ Garbage Collector и находится в состоянии «работает, ничего не портит, вот и славно». Недавно в компилятор была добавлена поддержка для precise garbage collection и вообще простая возможность менять стандартный компилятор на свой. В рамках последнего Google Summer of Code пресловутый precise gc был написан, но мне ничего не известно ни о планах по замене текущего на новый, ни о бенчмарках.

С .NET и JVM тут очень трудно конкурировать если играть по тем же правилам. Модуль, отвечающий за управление GC: dlang.org/phobos/core_memory.html

Но насчёт серверных приложений — использование gc ничуть не мешает vibe.d ( vibed.org ) смешивать всех с грязью в плане производительности, так что аделкое от совершенства качество сборщика мусора отчасти компенсируется возможностями языка по управлению моделью памяти.
0
Volfram, #
только сейчас заметил: не «менять стандартный компилятор» а «менять стандартный сборщик» конечно же
+1
wa_Nadoo, #
vibe.d приятно удивила. Посмотрел минут 15 примеры кода, напомнило замечательный фреймворк Play! в Java/Scala. С такими инструментами D может продвинуться в массы из-за пригодности к веб-деву.
0
csmile, #
Написал был в свое время под D1 harmonia GUI framework.

Из проблем которые были в то время:
1. D1 менялся радикально с каждым билдом, т.е. каждую неделю. Очень тяжело было shooting moving target.
2. Не ясен был принцип D.dll — т.е. создания компонент на D коде в DLL для non-D consumers. Единственынный способ «компонентизации» в D это компоненты в исходных текстах (т.е. статическая компиляция).

Вообще D хорош для «лохматых» проектов когда разумную политику владения (кто что создает а кто освобождает) трудно описать. Но приходится все хозяйство писать на D. С код (и DLL с plain C интерфейсами) можно ипользовать, но завимодействие с С++ и его new/delete уже известная проблема.

0
Volfram, #
Ого, это же целую вечность назад, я тогда ещё и слышать не слышал ни про какие D :) С тех пор многое поменялось, даже в D2 нет таких частых релизов, а уж обратную совместимость ломают только в совсем отчаянных случаях :)

DLL и сейчас является проблемной областью, но, в основном, из-за невозможности нормальной динамической линковки druntime и phobos, больно уж жирновато выходит. А вот насчёт взаимодействия с С++ — я как-то даже не знаю, даже С++ программы между собой общаются через plain C интерфейсы обычно. Отсутствие стандартного ABI + шаблоны = то ещё удовольствие.
+1
mib431, #
Скажите, а вы используете D в продакшене? Или это просто, условно говоря, хобби? Любопытно.
0
Volfram, #
Ох, мне в продакшене даже о С++ приходится только мечтать :) Или хоть о компиляторе С посвежее…
Основной язык для личных экспериментов в свободное от работы время, наверное, это можно назвать хобби, да.
0
ltwood, #
Периодически смотрю на D, но есть тяжелый груз — своя библиотека математики на C++, которая по разным причинам содержит еще и собственные контейнеры и прочую лабуду. С точки зрения ентерпрайз-программирования все проекты довольно маленькие, но очень специфичные (электронная микроскопия, томография, эндоскопия, потоковое аудиораспознавание) и удельная стоимость строчки кода (условно говоря) очень высокая. Все внешние интерфейсы на чистом ANSI-C, даже если с другой стороны GUI, также написанное на C++. Сейчас появились ресурсы, позволяющие стартовать пару новых проектов на D. Из библиотеки я бы перетаскивал по мере необходимости только нужное в данный момент. Насколько это самоубийственно по Вашему мнению?

Upd. Да, забыл сказать, еще и система сборки проектов собственной разработки, слегка похожий на jam. И еще самодельная интеграция с lua, но с этим проблем быть не должно.
0
Volfram, #
С удовольствием могу сказать, что ваша ситуация обещает наименьшее количество проблем :) Как минимум, мне известно успешное использование D в области биоинформатики, что выглядит как тема, похожая по подборке инструментов. Если интерфейсы на чистом ANSI-C, то из библиотеки перетаскивать ничего не потребуется, можно использовать её напрямую. Проблема может возникнуть только с этим: d.puremagic.com/issues/show_bug.cgi?id=5570. Если нацелены на x64 системы, я бы подождал, пока этот баг не закроют.

Система сборки не важна, у D нет «православной» системы сборки.

Если интересуют какие-то конкретные вопросы — буду рад помочь, дам адрес электронной почты по пингу в личку.
0
ltwood, #
Да, мне тоже кажется, что не должно быть особых проблем.

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

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

А как там с вещественной арифметикой в ее самых грязных проявлениях? Имеется в виду такая ужасная вещь как people.sc.fsu.edu/~jburkardt/c_src/paranoia/paranoia.html :)
0
Volfram, #
Имеется в виду, что если API библиотеки объявлено как extern «C», то можно её линковать напрямую с программами на D, он понимает C ABI. Если C++ — тоже можно, но чревато большей головной болью.

Вещественная арифметика:
dlang.org/d-floating-point.html
dlang.org/phobos/std_numeric.html
dlang.org/phobos/std_math.html
Я не очень силён в этой теме, так что, думаю, вам эти ссылки скажут больше, чем мой пересказ.
0
lxyd, #
Скажите, а по каким ресурсам вы D изучали?
Может, есть какая-нибудь свежая книжка? А то в издании 2010го года первый же пример отказывается собираться без допиливания.
Я совсем недавно начал его щупать, сейчас пробую всякие простейшие возможности языка и фобоса, так приходится иногда в исходники залезать.
0
Volfram, #
1) TDPL от Александреску. Там могу быть проблемы со сборкой примеров, особенно в старом издании, но это основной источник представления о _намерениях_ авторов языка.
2) официальные доки с dlang.org — для рутинной разибрательства «баг компилятора или я не очень?»
3) forum.dlang.org/group/digitalmars.D.learn и stackoverflow.com если ничего не помогает

Примерно на 2/3 переведена с турецкого отличная книга ddili.org/ders/d.en/index.html — если TDPL больше рассуждения и дизайн-решениях, то Ali Çehreli написал именно подробное руководство для новичков.

Мне было проще, т.к. я внимательно изучал содержимое forum.dlang.org в течение года-полутора до того, как реально что-то начал писать, там часто бывают очень познавательные дискуссии :)
0
lxyd, #
Спасибо!
1) У TDPL старое издание — это какое. Я вообще только одно нашёл (за 2010 год). Хотел купить, но сначала скачал с торрентов и упёрся в такое вот положение дел с примерами :( Решил подождать пока.
2) Кстати, а баги сейчас часто встречаются? А то я с промежутком в несколько дней наткнулся сначала на неработающий поиск Бойера-Мура, а потом на то, что commonPrefix для строк отдаёт результат, обрубленный посреди кодюнита. Вот и думаю, то ли лыжи не едут, то ли я чего-то не понимаю, то ли std.algorithm заброшен сейчас в дальний угол.

Турецкую книжку посмотрю обязательно, благодарю :)
0
Volfram, #
У меня тоже 2010 года, возможно именно переизданий не было, но errata точно есть: erdani.com/tdpl/errata/

Баги встречаются довольно редко в пределах «idiomatic D», и довольно часто — если начинать экспериментировать :) dlang.org/bugstats.php как бы намекает. std.algorithm как раз в очень хорошем состоянии по моим ощущениям, пришлите тест кейсы личкой — разберусь, в чём дело.
0
lxyd, #
За еррату спасибо, посмотрю.
Про баги в личку написал.
0
LLIAMAH, #
Раз уж пошла такая тема: попробовал сегодня портировать один сишный хедер на D, все прошло нормально, кроме одной закавыки.
Есть там одна структура с виртуальными функциями вида:
struct CServerInterface
  {
   virtual int             __stdcall Version(void);
   virtual time_t      __stdcall TradeTime(void);
...
};

Судя по докам, struct нужно заменить на interface, поменял(иначе не компилируется, исходников этих функций у меня нету).
Как ни пытался комбинировать extern(C, C++, Windows), никак не получилось заставить это работать:
после того, как получаю указатель на CServerInterface, я пытаюсь вызвать Version(), но падаю с ошибкой:
First-chance exception at 0x33560004 in mtsrv.dev.exe: 0xC0000005: 0xC0000005.
Всё это происходит в dll-ке.

А так давно хотел попробовать, после того, как прочитал на русском призывы и доводы Александреску(не помню как называлась та статья).
0
LLIAMAH, #
Нашел ту статью: Александреску, Андрей The Case for D.
www.linux.org.ru/news/opensource/4243077/page3
+1
Volfram, #
Она и на хабре есть, я участвовал в её переводе :)

По теме: я никогда не пробовал интерфейс напрямую с С++ и никому не советую, даже если формально оно поддерживается :) Отсутствие стандартного ABI чревато проблемами в дальнейшем. А в plain C struct остаётся struct.

Если можете подсократить код до минимально проблемного — вышлите личкой, посмотрю.
0
LLIAMAH, #
Спасибо за перевод! Меня вы зажгли =) Получится портировать — заинтересую коллег по работе и попробую в продакшене на простых вещах.
0
LLIAMAH, #
В целом вроде(пока с проблемами не сталкивался) получилось заставить работать программу.
Сделал как написано здесь dlang.org/cpp_interface.html, хотя удивился — вроде передаем указатель на CServerInterface, а принимаем по значению, и все работает:
//изначально было так:
//int  __stdcall        MtSrvStartup(CServerInterface *server);
export extern (Windows)
int MtSrvStartup(CServerInterface server)
{
//здесь уже можно обращаться к server
...
}

Сам интерфейс объявил таки вот так:
extern(C++){
interface CServerInterface
  {
   extern (Windows){
	   int         Version();
	   time_t      TradeTime();
           //остальные функции интерфейса
          ...
    }
  }
}
0
Volfram, #
Классы в D — исключительно полиморфные ссылочные типы, в отличие от структур. Они никогда не передаются по значению. CServerInterface всегда будет неявным указателем.

Вообще если с такими сигнатурами и без дополнительных хаков завелось — могу только порадоваться и позавидовать, как разработчик под Linux :) Тут всё куда интереснее, банальным extern©/extern(C++) динамическую либу не завести.

Да, как у же упоминал в личке, у портирования под dll есть своя специфика, описанная тут: dlang.org/dll.html. Опять же, сам не проверял, ибо Windows.
0
lostdj, #
Скорее всего из-за того, что это виртуальные методы. Баг ли, должен D такое уметь?

Решение обычное: обернуть вызовы этих методов в сишные (cdecl) функции.

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