Вышли новые версии оригинальных компиляторов языков D2 и D1

> Да хотя бы то, что в следующией версии языка сломают совместимость

Это легенды бабушек, не слушайте их. :) Последнее важное изменение касалось строк (char[] отличался от string), всё остальное работало как и прежде. Кроме того, нет смысла отрекаться от языка просто потому, что вы параноидально боитесь ПРИДУМАННЫХ изменений. Ди уже около 3 лет стабилен, ничего страшно радикального в нём не появится. Да и разработчики языка прекрасно понимают ваши опасения - можете написать Уолтеру и он вас успокоит. :)

dmd умеет использовать gcc в качестве бэкенда?

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

http://digitalmars.com/d/2.0/htomodule.html http://digitalmars.com/d/2.0/htod.html import std.c.*;

http://www.digitalmars.com/d/2.0/ctod.html относится только к тем, кто почему-то решил С код сконвертировать на D. Не надо этого делать, надо уметь прозрачно линковаться с Си кодом.

с с++ кодом, действительно, чуть сложнее: http://www.digitalmars.com/d/2.0/cpptod.html --- если конвертировать исходник.

Линковаться сложнее из-за манглинга С++. Стандартный способ (QtD,OpenMorrowind) — генерация C врапперов для С++ кода. В QtD это проще потому что есть патченный QtJambi.

Внезапно, можно использовать llvm компиляторы, clang и ldc и линковаться используя возможности LLVM. Так проще.

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

Кто-нибудь может толком объяснить, что это за волшебный LLVM и нахер он нужен? Столько раз его упомянули в теме...

>> А что в D вам мешает писать так же, как в Си??

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

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

> Ну и почему ты считаешь что джава «мертворожденная»?

А ты посмотри где сейчас Жаба. :) На десктопе - НОЛЬ, на серверах все уже наелись «иджыбинами» и пишут на чём попало. Мобильный сегмент? Ну разве что... Опять же, чисто коммерчески. А как язык жаба отстаёт даже от Сишарпа, не говоря о Ди. Только не проси меня тратить моё время для ублажения чьего-то любопытства - почитай про Ди, а потом посмотри, что из прочитанного есть в жабе - всплакнёшь. :)

С чего бы ему уметь это? dmd это компилятор Волтера Брайта на базе его тулчейна dmc, Digital Mars C++ http://www.digitalmars.com/features.html который есть компилятор, отдельно выдранный и доработанный из Symantec C++, который есть доработанный ещё более мохнатый компилятор С++ (как бы не Zortech C++), который был единолично написан Волтером Брайтом году так в 1986 и был первым настоящим компилятором (а не препроцессором вроде CFRONT)

dmd = DDMD + dmc тулчейн (линкер OPTLINK + make).

DDMD это фронтэнд отодранный от dmd, какое-то время его не было, потом не развивался, сейчас он синхронизирован с dmd. Ещё есть пара компиляторов D на самом D.

ldc = LLVM компилятор + свой фронтэнд, но по они регулярно синхронизируют его с DDMD

gdc = GCC + опять-таки, свой фронтэнд, по-моему, независимый от ddmd, из-за чего и получается такой относительно медленный темп разработки GDC.

Отдельный DDMD + компилятор в виде плагина под gcc 4.5 сильно бы упростил поддержку.

> сравним производительность реализации одних и тех же алгоритмов на C и D

кстати да - наличие D тут:

http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest...

помогло бы сравнить скорость, объем кода, и собс-но посмотреть как выглядит код на D на более-менее реальных задачах

>В Object Pascal были какие-то оригинальные идеи? А CTFE и шаблоны там были?

насчет хлоротрифтороэтилена (CTFE) не знаю, а шаблоны модульность, юникодовые строки по умолчанию и многое другое чем хвалиться D там есть

> Я уж молчу про модули ядра, демоны и системные либы, которые кроме как на С,С++ или ассемблере писать противопоказано.

segfault

>Линк на документацию можно?

Если приглядеться, второе предложение поясняет первое.

Капитан, самому можно и сборку мусора можно написать.

Вот и ответ на вопрос о циклических ссылках.

Не понятно, какую нишу он собирается занять. Поэтому за столько лет никто им всерьез и не заинтересовался. Как по мне, нынче все попилено C, Java и Python.

>> В Object Pascal были какие-то оригинальные идеи? А CTFE и шаблоны там были?

насчет хлоротрифтороэтилена (CTFE) не знаю

отличнаяшутка.жпг

шаблоны

Хм, и давно в Object Pascal появились шаблоны?

Ну то есть не существует готовых реализаций смарт-пойтнеров, работающих с циклическими структурами, о чем и речь.

> нынче все попилено C, Java и Python.

а также PHP, С#, Obj-C, С++, JS

>Хм, и давно в Object Pascal появились шаблоны?

Уже давненько

> А учитывая «Си-совместимость» Ди, ваши существующие либы даже не надо переписывать - их можно портировать!

да и просто слинковать можно:

gcc -c sqlite.c -o sqlite.o
dmd mysqlite-CRUD.d sqlite.o -o MEGA-CRUD-APP
./MEGA-CRUD-APP


или, gdc -c ... / ldc mysqlite-CRUD.d -o mysqlite-CRUD.ll -output-ll
(или *.bc -output-bc).

Кстати, llvm умеет конвертировать BC код в C.

ldc:

version(build) pragma(link,«sqlite»);

pragma (intrinsinc,...)


врапперы (sqlite.d) нужно писать, если мы хотим ООП интерфейс к С либам (как в С++).
Если не хотим, а хотим только уметь линковаться, в С++ нужно написать хедер с extern «C» { #include «c-header» }; , а в D нужно написать module foo; extern (C): и вручную скопипастить c-header. Это так сложно?

вон к примеру, враппер к SDL: http://www.dsource.org/projects/ldc/browser/demos/sdl.d

хотя надёжнее не скопипастить, а прогнать через htod

разные компиляторы, разные бекенды, разные оптимизации. Пока что у LDC лучше всех с качеством оптимизированного кода, за ним идёт gdc, за ним референсный dmd. Зато dmd самый быстрый.

torus trooper, же (врочем, он собирается с помощью gdc).

CTFE = compile time function execution.

что ж, потыкаем веточкой

ИМХО уже давно назрела необходимость языка, который может выполняться как скрипт, интерпретироваться в виде байткода, компилироваться в нативные бинари и работать поверх JVM/Mono(.net)... Пока что такой язык это питон (хоть я его и не очень жалую).

Потенциально, таким языком мог быть D, что есть гуд, но что там с байткодом? .net порт устарел, JVM не держится. Буду рад если ошибся в каком-то пункте.

да, его кажется собирали под Arm. Какая-то японская игрушка под Arm через gdc собиралась.

из довольно объёмного кода есть Deadlock — Quake подобная игрушка на D by team0xf ( h3r3tic и остальные), линкер xfbuild by team0xf, компиляторы на самом D, QtD.

> В Object Pascal были какие-то оригинальные идеи? А CTFE и шаблоны там были?

мне в VCL показалось вполне оригинальной идеей методы классов, классы и метаклассы, и реализация RTTI, которая там очень активно использовалась.

> выполняться как скрипт, интерпретироваться в виде байткода, компилироваться в нативные бинари
OCAML что ли? Хотя я его синтаксис, если честно, так и не осилил.

Это все узкоспециализированные решения.

> разные компиляторы, разные бекенды, разные оптимизации

но ведь должен быть стандарт? когда я пишу на С++ для linux/mac - я знаю, что тут лучше всего взять gcc, для win - Visual C++, а для D получается не так?

>Ну то есть не существует готовых реализаций смарт-пойтнеров, работающих с циклическими структурами, о чем и речь.

Речь о том, что утверждение «в C++ нет сборки мусора» не верно. Из коробки нет, но кому надо - пишут, а кому надо и не хочется писать - гуглят. Только, как показывает практика, мало кому это надо и проблема циклических ссылок совсем не так фатальна.

Конкретно по смарт-поинтерам: shared_ptr/weak_ptr отлично работают с циклическими структурами.

> Это все узкоспециализированные решения.

чем питон универсальней того же C#, например?

> Речь о том, что утверждение «в C++ нет сборки мусора» не верно.

Просто у тебя свое, глубоко личное, понимание этого утверждения как «если можно написать, значит есть».

В стандарте языка есть GC? Нет. В какой-нибудь распространенной реализации есть? Нет. Значит, ее нет в языке Си++

Конкретно по смарт-поинтерам: shared_ptr/weak_ptr отлично работают с циклическими структурами.

Ссылку на документацию можно?

тогда уж под мак надо брать не g++, а родной objective-C clang компилятор.

стандарт на что ? на язык? он реализован во всех трёх компиляторах, с незначительными отличиями в бекендах

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

стандартных рантайм библиотек 2 — от Брайта и Александреску и от сообщества. Стандартных инструментов сборки тоже 2 или больше.

Просто в D сам DMD/phobos от автора не сильно лучше ldc/tango от сообщества, с точки зрения кодогенерации. Это как под мак сравнивать для Objective C приложений gcc и clang — clang лучше, а gcc легаси. и т.п. это распыляет сообщество, но чем больше выбора, тем лучше.

CTFE = compile time function execution.

Паскаль высчитывает выражения во время компиляции. А эта штука, конечно полезна, но польза от нее мизерна.. Зато сомневаюсь что компилятор D хоть чуть-чуть приближаеться к компиляторам Паскаля по скорости компиляции) И тем более сомневаюсь что он далеко ушел от С++ в этом плане..

> тогда уж под мак надо брать не g++, а родной objective-C clang компилятор.

только когда он будет официально, т.е. с четвертой версии xCode и судя по всему с 10.7.0

стандарт на что ?

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

>Просто у тебя свое, глубоко личное, понимание этого утверждения как «если можно написать, значит есть».

В стандарте языка есть GC? Нет. В какой-нибудь распространенной реализации есть? Нет. Значит, ее нет в языке Си++

В моем понимании что-то есть, если это существует в реальности. В твоем понимании что-то есть, если оно прописано в стандарте или наличествует в libstdc++. Очевидно, у кого из нас понимание личнее.

Ссылку на документацию можно?

Подвох какой-то что ли: http://www.boost.org/doc/libs/1_46_0/libs/smart_ptr/smart_ptr.htm

> В моем понимании что-то есть, если это существует в реальности. В твоем понимании что-то есть, если оно прописано в стандарте или наличествует в libstdc++

кстати в С++0х «узаконили» smart_ptr и weak_ptr

> Зато dmd самый быстрый.

О да, это самое важное преимущество для компилятора.

у D есть либа для работы с сетью?

> у D есть либа для работы с сетью?

как минимум есть привязка к Qt - QtD

> язык то один, но уже имеет две версии и время от времени что-то меняется,

причём в таком состоянии он уже довольно долго.

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

вот фронтенд DDMD и есть стандартный компилятор для D.
А тулчейны, в котором он реализован, разные:
dmd = DDMD собранный gcc слинкованный ld + ld на линуксе, фри и макоси; dmd = DDMD собранный dmc и слинкованный OPTLINK + OPTLINK на винде;
ldc = свой простой бекенд с бекпортированным туда DDMD, собранный gcc + llvm + ld;
gdc = свой сложный бекенд с бекпортированным туда DDMD, собранный gcc + ld.

из систем сборки сейчас практически стандартен xfbuild.

есть много нюансов -

всё-таки не понял, на что стандарт-то. Стандартная реализация ? Ну да, можно считать ей dmd. Референсная реализация спек языка. Лучшая кодогенерация и тулчейн с минимумом глюков — есть и другие варианты.

есть. А что надо?

а ссылку можно?

D2, phobos:
http://www.digitalmars.com/d/2.0/phobos/std_socket.html
http://www.digitalmars.com/d/2.0/phobos/std_socketstream.html
http://www.digitalmars.com/d/2.0/phobos/std_uri.html
http://www.digitalmars.com/d/2.0/phobos/std_xml.html
http://www.digitalmars.com/d/2.0/phobos/std_concurrency.html
http://www.digitalmars.com/d/2.0/phobos/std_base64.html
http://www.digitalmars.com/d/2.0/phobos/std_json.html
std.linux/std.c.linux/

D1, phobos:
аналогично
D1, tango:
http://www.dsource.org/projects/tango/wiki/Examples#Networking
http://www.dsource.org/projects/mango
HTTP server: http://www.dsource.org/projects/sendero
ASP/JSP/PHP: http://www.dsource.org/projects/dsp
сервер приложений http://www.dsource.org/projects/d_server_platform
FastCGI модуль http://www.dsource.org/projects/fastcgi4d

на talks.dprogramming.ru, когда он работал, кто-то писал свои server pages на D. Возможно, его можно найти на в жаббере на d@conference.jabber.ru

>>Ссылку на документацию можно?

Подвох какой-то что ли: http://www.boost.org/doc/libs/1_46_0/libs/smart_ptr/smart_ptr.htm

Никаких подвохов. Просто когда я процитирую это:

Because the implementation uses reference counting, cycles of shared_ptr instances will not be reclaimed.

я хочу, чтобы цитата пришла со ссылки, которую дал ты.

> QtD
OMG. У языков, претендующих на звание высокоуровневых, такие простейшие вещи должны быть в наличии. Qt в данном случае должен рассматриваться исключительно как GUI toolkit. Хороший пример - Python.

> ИМХО уже давно назрела необходимость языка, который может выполняться как скрипт, интерпретироваться в виде байткода, компилироваться в нативные бинари и работать поверх JVM/Mono(.net)... Пока что такой язык это питон (хоть я его и не очень жалую).

Не только питон, но и разные реализации схемы подходят под это дело. Куда уж без лиспа? ;)

На С# я там не обратил внимания. В любом случае толку от него чуть, ибо ниша, на которую он ориентирован, занята Java.

есть практически всё, что относится к сети: сокеты, HTTP/FTP/mail, HTTP сервер, CGI/xSP сервер, сервер приложений и т.п.
Наиболее толковой стандартной библиотекой является Tango, http://www.dsource.org/projects/tango/wiki/ChapterNetworking, впрочем в D2 Phobos тоже кое-чему научился.