Классы в D — исключительно полиморфные ссылочные типы, в отличие от структур. Они никогда не передаются по значению. CServerInterface всегда будет неявным указателем.
Она и на хабре есть, я участвовал в её переводе :)
По теме: я никогда не пробовал интерфейс напрямую с С++ и никому не советую, даже если формально оно поддерживается :) Отсутствие стандартного ABI чревато проблемами в дальнейшем. А в plain C struct остаётся struct.
Если можете подсократить код до минимально проблемного — вышлите личкой, посмотрю.
У меня тоже 2010 года, возможно именно переизданий не было, но errata точно есть: erdani.com/tdpl/errata/
Баги встречаются довольно редко в пределах «idiomatic D», и довольно часто — если начинать экспериментировать :) dlang.org/bugstats.php как бы намекает. std.algorithm как раз в очень хорошем состоянии по моим ощущениям, пришлите тест кейсы личкой — разберусь, в чём дело.
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 в течение года-полутора до того, как реально что-то начал писать, там часто бывают очень познавательные дискуссии :)
Ох, мне в продакшене даже о С++ приходится только мечтать :) Или хоть о компиляторе С посвежее…
Основной язык для личных экспериментов в свободное от работы время, наверное, это можно назвать хобби, да.
1.2 — помимо x86 мне известно об успешном запуске под ARM/Linux. В теории должно без большой головной боли заводится всё, что поддерживает backend и что достаточно posix-compliant, чтобы на нём с пол пинка собрался druntime.
Если интересует именно фреймворк «всё включено», то да, единственный. А так есть, например, ещё и github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff — этот добрый молодец ведёт коммерческую разработку сайтов на D2 уже несколько лет в связке с fastCGI. Выше уже упомянули, что веб-клиент к официальным newsgroup тоже написан на D2.
По vibe.d собираюсь делать отдельный обзор в ближайший месяц-два.
Ого, это же целую вечность назад, я тогда ещё и слышать не слышал ни про какие D :) С тех пор многое поменялось, даже в D2 нет таких частых релизов, а уж обратную совместимость ломают только в совсем отчаянных случаях :)
DLL и сейчас является проблемной областью, но, в основном, из-за невозможности нормальной динамической линковки druntime и phobos, больно уж жирновато выходит. А вот насчёт взаимодействия с С++ — я как-то даже не знаю, даже С++ программы между собой общаются через plain C интерфейсы обычно. Отсутствие стандартного ABI + шаблоны = то ещё удовольствие.
Модель памяти уровня языка в D сложнее, оттого несколько другие задачи при дизайне. Деструкторы детерменированны, время жизни объекта под контролем сборщика мусора — нет. Деструкторы стэковых объектов ( структуры, например) вызываются при выходе из области видимости гарантированно. Точно так же возможно явно использовать destroy для вызова деструктора, но детерменированно освободить принадлежащую gc память — нет.
Про костыли сказать не могу, т.к. мне это не кажется костылём, но плохо задокументированной частью языка, которая требует переосмысления подхода к дизайну :) Я затрудняюсь придумать хоть одну фичу С++, аналогия которой в D будет выглядеть костыльнее.
А вообще из неожиданностей — у структур не может быть конструктора по умолчанию, const/immutable/shared — транзитивны, глобальные переменные thread-local по умолчанию.
Выпад в сторону шаблонов не понял, т.к. при переходе это скорее «убрать костыли на С++ и написать нормально на D».
Легко, сборщик мусора в 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 ) смешивать всех с грязью в плане производительности, так что аделкое от совершенства качество сборщика мусора отчасти компенсируется возможностями языка по управлению моделью памяти.
Тогда согласно приведённой вами цитате из TDPL. Если это управляемая GC куча. Если память была выделена через malloc & Co — то как в plain C, только руками.
О, это хороший вопрос и отличное напоминание о том, что стоит бы потереть устаревшую документацию на офф. сайте.
Основной предлагаемый способ 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.
По хорошему, надо пройтись по репозиторию с доками офф. сайта и вычистить всё это. Я даже собирался заняться, но это как минимум пара дней нуднейшей вычитки спеков и пока не собрался: )
Почему станет лучше — а) исчезнет привязка аллокации в phobos на garbage collector, станет возможным использование всей стандартной библиотеки вообще не включая gc в приложение б) это будет означать зелёный свет для добавление продвинутых контейнеров в стандартную библиотеку.
Это не совсем так. Garbage collector и ручное управление памятью прекрасно соседствуют в D бок о бок. Некоторые известные мне проекты используют предаллоцированные пулы памяти управляемые вручную для основной массы данных и garbage collector — для «менеджерских» задач, поддержки делегатов и тому подобных плюшек. Получается довольно практично.
Другое дело, если существование garbage collector для вас вообще непримлемо, даже в качестве скулящего в углу бедного родственника. Тогда да, про phobos придётся забыть, т.к. там может выделяться память, которая начнёт течь. С другой стороны, вся стандартная библиотека С все ещё в полном распоряжении, так что относительно С вы ничего не теряете.
Когда Александреску опубликует спеки по аллокаторам ( он очень серьёзно относится к их дизайну и не хочет ничего показывать, пока не будет наверняка ) ситуация просто превратится из нормальной в великолепную: )
Это очень обширная тема, даже на хабре уже есть штук 5 статей на тему обзора плюшек D. В один комментарий по-хорошему не уложусь. Попробую совсем бегло.
Быстродействие при сравнении gdc vs gcc — одного порядка, больше зависит от мастерства разработчика, чем от особенностей языка. Память — зависит от того, сколько волностей разрешаете garbage collector. Стартовый overhead выше за счёт druntime, но потребление памяти приложением как таковым полностью зависит от выбранной модели работы с оной. Скорость и удобство разработки — в пользу D на порядок, без преувеличений, просто не сравнимые вещи.
Кроссплатформенность, конечно, возможна, на сейчас как раз идёт бета-тест версии DMD с поддержкой Win64 и COFF формата, после его релиза базовый набор Linux/Windows/Mac 32/64 будет поддержан в полном виде. ARM — через GDC.
Прелести в сравнении с С++ навскидку:
— система шаблонов, изначально спроектированная для массового использования, в отличии от случайной находки С++
— полноценные делегаты и иже с ними
— более мощная система типов за счёт доп. гарантий от компилятора и способов статической интроспекции
— ranges ( дальнейшее развитие итераторов ) как базовое понятие языка и основа дизайна как встроенных массивов, таки и стандартной библиотеки
Вообще если с такими сигнатурами и без дополнительных хаков завелось — могу только порадоваться и позавидовать, как разработчик под Linux :) Тут всё куда интереснее, банальным extern©/extern(C++) динамическую либу не завести.
Да, как у же упоминал в личке, у портирования под dll есть своя специфика, описанная тут: dlang.org/dll.html. Опять же, сам не проверял, ибо Windows.
По теме: я никогда не пробовал интерфейс напрямую с С++ и никому не советую, даже если формально оно поддерживается :) Отсутствие стандартного ABI чревато проблемами в дальнейшем. А в plain C struct остаётся struct.
Если можете подсократить код до минимально проблемного — вышлите личкой, посмотрю.
Баги встречаются довольно редко в пределах «idiomatic D», и довольно часто — если начинать экспериментировать :) dlang.org/bugstats.php как бы намекает. std.algorithm как раз в очень хорошем состоянии по моим ощущениям, пришлите тест кейсы личкой — разберусь, в чём дело.
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 в течение года-полутора до того, как реально что-то начал писать, там часто бывают очень познавательные дискуссии :)
Основной язык для личных экспериментов в свободное от работы время, наверное, это можно назвать хобби, да.
1.2 — помимо x86 мне известно об успешном запуске под ARM/Linux. В теории должно без большой головной боли заводится всё, что поддерживает backend и что достаточно posix-compliant, чтобы на нём с пол пинка собрался druntime.
Про android всё верно понимаете.
По vibe.d собираюсь делать отдельный обзор в ближайший месяц-два.
DLL и сейчас является проблемной областью, но, в основном, из-за невозможности нормальной динамической линковки druntime и phobos, больно уж жирновато выходит. А вот насчёт взаимодействия с С++ — я как-то даже не знаю, даже С++ программы между собой общаются через plain C интерфейсы обычно. Отсутствие стандартного ABI + шаблоны = то ещё удовольствие.
Про костыли сказать не могу, т.к. мне это не кажется костылём, но плохо задокументированной частью языка, которая требует переосмысления подхода к дизайну :) Я затрудняюсь придумать хоть одну фичу С++, аналогия которой в D будет выглядеть костыльнее.
А вообще из неожиданностей — у структур не может быть конструктора по умолчанию, const/immutable/shared — транзитивны, глобальные переменные thread-local по умолчанию.
Выпад в сторону шаблонов не понял, т.к. при переходе это скорее «убрать костыли на С++ и написать нормально на D».
С .NET и JVM тут очень трудно конкурировать если играть по тем же правилам. Модуль, отвечающий за управление GC: dlang.org/phobos/core_memory.html
Но насчёт серверных приложений — использование gc ничуть не мешает vibe.d ( vibed.org ) смешивать всех с грязью в плане производительности, так что аделкое от совершенства качество сборщика мусора отчасти компенсируется возможностями языка по управлению моделью памяти.
Довольно давно не обновлялось, впрочем, не знаю насколько сейчас юзабельно.
Gtkd поддерживается сейчас несколько активнее.
Основной предлагаемый способ RAII шаблон scoped!T: dlang.org/phobos/std_typecons.html#scoped
Создаёт экземпляр класса на стеке, запрещает любое его присваивание, при выходе из scope вызывается деструктор, а состояние объекта вырождается в T.init. Реализовано через структуру с полем аналогичного классу размера, alias this и emplace.
Не вполне RAII по букве, но решает ту же задачу — scope(exit) / scope(success) / scope(failure). Формата:
Когда-то предполагалось использовать для этих целей специальные scope классы, которые имеют специальные правила по аллокации. И спеки ещё можно найти на сайте, и оно ещё работает. Но считается deprecated из-за небезопасного диазайна и оттого не упоминается в TDPL.
По хорошему, надо пройтись по репозиторию с доками офф. сайта и вычистить всё это. Я даже собирался заняться, но это как минимум пара дней нуднейшей вычитки спеков и пока не собрался: )
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 в приложение б) это будет означать зелёный свет для добавление продвинутых контейнеров в стандартную библиотеку.
Во-вторых, я подозреваю, что автор оригинального текста упомянул те, над которыми ведется активная работа именно сейчас.
P.S. Хотя, как вижу, у D-IDE тоже совсем недавно были коммиты, это отрадно.
Другое дело, если существование garbage collector для вас вообще непримлемо, даже в качестве скулящего в углу бедного родственника. Тогда да, про phobos придётся забыть, т.к. там может выделяться память, которая начнёт течь. С другой стороны, вся стандартная библиотека С все ещё в полном распоряжении, так что относительно С вы ничего не теряете.
Когда Александреску опубликует спеки по аллокаторам ( он очень серьёзно относится к их дизайну и не хочет ничего показывать, пока не будет наверняка ) ситуация просто превратится из нормальной в великолепную: )
Быстродействие при сравнении 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»