В свободный компилятор LDC (https://github.com/ldc-developers/ldc/), развиваемый на базе наработок проекта LLVM, добавлена (https://wiki.dlang.org/Generating_WebAssembly_with_LDC) поддержка компиляции кода на языке D в промежуточный код WebAssembly для выполнения в web-браузерах. Представленная возможность позволяет создавать обработчики на языке D, которые можно использовать в web-приложениях. Поддержка кросс-компиляции в WebAssembly интегрирована в тестовую версию LDC 1.11.0-beta2 (https://github.com/ldc-developers/ldc/releases/), опубликованную несколько дней назад.
Кроме того, выпущено (https://dlang.org/blog/2018/07/04/dmd-2-081-0-released/) обновление основного эталонного компилятора DMD 2.081.0 (https://github.com/dlang/dmd/). В новом выпуске проведена работа по улучшению переносимости с проектами C++ и представлена поддержка нового синтаксиса для контрактного программирования (https://ru.wikipedia.org/wiki/%D0%9A%D0%... предложенного в рамках спецификации DIP 1009 (https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1... (D Improvement Proposal). Компилятор DMD поддерживает системы GNU/Linux, Windows, macOS, FreeBSD, и архитектуры x86, x86_64, x64.Напомним, что язык D использует статическую типизацию, обладает синтаксисом, схожим с C/C++, и обеспечивает производительность компилируемых языков, при этом заимствуя некоторые полезные возможности динамических языков в области эффективности разработки и обеспечения безопасности. Например, предоставляется поддержка ассоциативных массивов, косвенное определение типов, автоматическое управление памятью, средства параллельного программирования, опциональный сборщик мусора, система шаблонов, компоненты для метапрограммирования, возможность использовать библиотеки на языке C, а также некоторые библиотеки на C++ и Objective-C.
URL: https://dlang.org/blog/2018/07/04/dmd-2-081-0-released/
Новость: https://www.opennet.me/opennews/art.shtml?num=48983
>Кроме того, выпущено обновление основного эталонного компилятора DMD 2.081.0.Да уже 2.081.1 выпущено какбе.
Я вот этого ток не понял
>Constructor/destructor mangling matches C++
>Compatible D style operators now mangle as C++ operatorsЭто то о чем я думаю, и теперь не надо делать врапперы с костыльным createInstance?
И чего бы им это mangle изначально было не сделать совместимым с C++?
Например, потому, что есть минимум две взаимонесовместимые схемы mangling-а -- GCC и MSVC. И это не считая периодических изменений, вызванных необходимостью адаптировать эти схемы под фичи новых стандартов языка.
LDC всегда немного отстает. Нужны плюшки - DMD, нужен релиз - LDC.
Кто-то тут использует D? не вижу смысла в этом языке, есть С/С++, Go, Rust
В D такой же смысл, как и в Rust, тем более он появился раньше
> В D такой же смысл, как и в Rust, тем более онто есть, никакого.
> появился раньше
тем более, ага.
>> В D такой же смысл, как и в Rust, тем более он
> то есть, никакого.синтаксис, если будут вопросы - то делаем выводы по таковому из java, C#, etc...
не вижу смысла в плюсах, когда есть няшная сишка для низкоуровневых (и не очень) дел, не-гиперпереусложненные D/Vala для "си с классами", ну и Java для высокоуровневого надежного энтерпрайз-кода.
Няшная сишка, риали?
Да одно сравнение char* vs std::string / QString показывает всю антиняшность "простого" языка C :)
А кто-то мешает использовать либы под си? Я вот glib в своих поделках использую.
Дак сравни char* vs std::string::c_str(). Что ты указатель сравниваешь с объектом?
При чем тут? Сравнивается подход и удобство.
> std::string::c_str()Это всего лишь один из 'view' для строки, причем read only
> char*
это может быть что угодно. Обычно считается, что это null-terminated строка, но находятся уникумы, что используют это вместо uint8_t*.
> но находятся уникумы, что используют это вместо uint8_t*например, сами разработчики языка, которые никакого ^^^ не изобретали.
зато работали на машине, где процессор работал не с байтами, а со "словами", непременно выравненными, а для байтов был отдельный набор команд. Поэтому им понадобился int и char, совершенно не отражающие того факта, что первое для цифр а второе для букв. bcpl обходился типом "byte".
Точнее, (char * + size_t) vs std::string. Терминированная 0-м строка - давно уже архаизм, хотя и используется повсеместно.
> Терминированная 0-м строкаявляется фичей почти всех существующих процессоров - если даже не в виде команд, работающих непосредственно с такой строкой, то хотя бы в особенностях инструкций jz/jnz, использующих результат предыдущей операции БЕЗ необходимости отдельно сравнивать его с чем либо.
когда язык C только писали, второе уже было.
как только вы изобретете процессор, работающий с паскалевскими строками столь же эффективно - можно будет считать эту фичу "архаизмом".
>> Терминированная 0-м строка
> является фичей почти всех существующих процессоров - если даже не в виде
> команд, работающих непосредственно с такой строкой, то хотя бы в особенностях
> инструкций jz/jnz, использующих результат предыдущей операции БЕЗ необходимости отдельно
> сравнивать его с чем либо.Т.е. в вашей вселенной дешевле каждый раз искать конец строки проходом, вместо одноразового запоминания длины? Интересно!
> как только вы изобретете процессор, работающий с паскалевскими строками столь же эффективно
> - можно будет считать эту фичу "архаизмом".Я вас огорчу, но у нас, для эффективной работы уже давно сохраняют длину строки и тянут ее с собой. Потому что в нашей вселенной загрузить эти данные выйдет быстрее, чем исать 0x0 в куске памяти, даже с помощью SIMD.
Да и std::string для плюсов у нас тоже делали, не послушав опеннетных знатоков.
в нашей вселенной не нужно вообще искать конец null-terminated строки - именно для этого она null-terminated.Есть задача с этой строкой что-то сделать, и не уехать за ее край. И вот второе - со времен dec pdp11 - не требует никакой отдельной операции. Просто команда процессора сама перестает выполняться, доперебирав символы до этого нуля.
а процессоры, поддерживающие паскалевские строки, у нас неизвестны.
> в нашей вселенной не нужно вообще искать конец null-terminated строки - именно для этого она null-terminated.Все может быть. У вас там может и релок дешевый и хип не фрагментируется, так что при вставке или соединении длинной строки можно на каждый чих переаллоцировать. И целого вагона уязвимостей на почве "тут же должен был быть \0! Мы ждали!" у вас там наверное нет. И работать со строками можно не спеша, загружая каждый знак по отдельности. Хорошо вам там.
> Есть задача с этой строкой что-то сделать, и не уехать за ее
> край. И вот второе - со времен dec pdp11 - не требует никакой отдельной операции. Просто команда процессора сама перестает выполняться, доперебирав символы до этого нуля.Познаково, ага.
Хочешь копировать или искать или еще что-то - можешь загружать за один заход 4-8-16 байтов (переход на 32-бита, появление MMX, SSE и т.д.), но будь любезен проверить все загруженные байтики на наличие 0.
Особенно доставляло при необходимости выравнивания для чтения в (x)mm - если строка короче, то больше потратишь на высчитывание смещения и прочую подготовку. Особо неверующие и теоретики могут глянуть оптимированные варианты сишных операций со строками.> а процессоры, поддерживающие паскалевские строки, у нас неизвестны.
У нас с незапамятных времен тот же штеуд умел.
Cтарые добрые repz, loopz.
Это если брать CISC c жирным микрокодом.Еще, до сих пор работает
mov REG, [strlen]
...
dec REG/sub REG, 4 (8,16,42)
jnz/jnb mysuperloop / CMOVXXX REG, REG
Как мне кажется попытка "улучшить" C++, только получилась наоборот ещё большая помойка.
Существенно меньшая. Особенно в метапрограммировании. Плюсы, конечно, с тех времён полдправили (кое-что стащив, и правильно) и дальше правят, но тяжёлая наследственность даёт о себе знать.
>RustНе вижу смысла в этом языке, есть D
В D уже завезли работающие без сборки мусора стандартные библиотеки?
Да без проблем. Пишешь с core.stdc
Т.е. по функционалу - голый C. Романтика, епть!
Нихрена не голый си. В си есть шаблоны? Вложенные функции, структуры, делегаты и лямбды? Члены стуктур, конструкторы, деструкторы и перегрузка операторов? Модули? Слайсы и проверка границ? scope(exit)? (специально хелловорлды не на сишке а на ди опенглные писал ибо вызывать все эти glfwTerminate - замучаешься, а scope(exit) - спасение, как его только на крестах не костылят). Фишки компилятора? Возможность дергать код на c++?
Да про фичи языка понятно, вот только предлагаемая либа без сборщика мусора - это либа голого C. Засунем шаблоны и лямбды в printf, ага. Сравниваем что есть в плюсах в стандартной либе, причем тоже всякой без сборки мусора. Вообще не понимаю, почему бы не сделать стандартную либу D в двух вариантах.
DLang вполне юзабельный язык. Хорошо продумана идеология и синтаксис. Программы по производительности не уступают C++, за то скорость компиляции существенно выше. Единственное, что из-за сборщика мусора программы получаются жирнее.
Скорость компиляции была выше, когда в Phobos было мало шаблонов и CTFE. Импортируйте std.regex и посмотрите, как увеличится время компиляции. И это при использовании DMD, который быстрее всех генерит "так себе" код. Захотите производительность на уровне C++ или выше - придётся использовать LDC, и компиляция будет как у C++.
google: newCTFE
Когда допилят и включат в стабильный выпуск, тогда и поговорим.
У кого-то после чтения моих комментариев могло сложиться впечатление, что я недолюбливаю D. В каком-то смысле, да. Он мне нравится, и я его использую уже лет 10, но в нём по-прежнему есть косяки, и глупо их отрицать.
я разработкой на php или javascript быстрее и больше денег заработаю, чем на D
А проституткой или менеджером еще больше.
а причём тут проституткой или менеджером?
обсуждение идёт языка программирования D, много ли вакансий на этот язык?
сами-то разработчики языка D чем деньги зарабатывают?
неужели разработчики языка D зарабатывают деньги проституцией или менеджментом?
> неужели разработчики языка D зарабатывают деньги проституцией или менеджментом?Наглая ложь, менеджментом они не занимаются.
Не все меряется вакансиями. Если на каком-то языке удобно написать большое приложение, и таких наберется штук 10, и они все взлетят - то и язык, считай, взлетел, независимо от вакансий. А если нет - то и с вакансиями не нать. Вон, на COBOL есть вакансии, не желаете прособеседоваться?
но если у этого языка ломают обратную совместимость, то это тупиковый выбор этого языка
Да, с этим у D хреново
Когда-то она всё равно должна ломаться. У C++ и PHP из-за обратной совместимости много странностей породилось.
Отличный язык, правда, как тут уже отметили, работу с ним не найти, но для пет-проектов или фриланса подойдёт вполне, сообщество бы ещё побольше, а то приходится половину нужных библиотек самому писать
а что отличного в этом языке D?
современный C++ намного лучше, чем D
увы, хуже.
Усложненное использование(порой много написать надо для простых вещей), многокилометровые трейсы с в случае глюков с шаблонами, множество тянущегося из глубины времен(хотя чуть чуть стали избавляться).
Даже чистый "C", лучше C++ - по крайней мере для системных целей.
что-то я сомневаюсь, что чистый C лучше C++, потому что в современном C++ уже давно есть умные указатели
Речь об архитектуре языка. В C в принципе не нужны всякие умные указатели. Для него это отжирающий ресы мусор. Его суть в простоте, а отсюда возможность писать компиляторы за месяц на любой тапок. А кому нужна безопасная работа с памятью, добро пожаловать в Rust, а в крайнем случае использовать библиотеки.
Согласен, до пассажа насчёт "чистого С" - кроме чего-то совсем уж низкоуровневого чистый С - это многословие и морока с обработкой ошибок.
А и не нужно его для чего-то большего использовать.
Он не лучше C++, если ты совладаешь с плюсами, то лучше взять их, но если тебе надо написать какое-нибудь приложение, какой-нибудь веб-сервис, то можно взять D, он прост, он по производительности близок к C и C++, у него есть пакетный менеджер, он быстро компилируется, не нужно заботиться об GC и по мелочи.
какой-нибудь веб-сервис я могу на Swift, Rust, go написать, и на C++ тоже можно написать.
Так кто тебе мешает? Язык нужно брать по удобности и возможностям, из всех перечисленных, этим языком оказался D, его и пользую
>>> Язык нужно брать по удобности и возможностяместь сомнения, что на C++ больше либ написано и есть обратная совместимость.
и я думаю, что на D никто не будет писать либы из-за того, что они сломают обратную совместимость.
Да, либ на крестах больше, но можно написать биндинги, если это что-то типа Qt или более навороченное, что сложно или долго переписать на dlang. C BC у D вроде бы всё в порядке, но многое очень часто летит в deprecated
Скорость компиляции, не?
>современный C++ намного лучше, чем DКогда к старости разберёшься во всех его особенностях и закоулках.
> Когда к старости разберёшься во всех его особенностях и закоулках.у тебя нет столько времени - осилил кое-как 11? марш разбираться в c++12!
> LDC, развиваемый на базе наработок проекта LLVM
> Поддержка кросс-компиляции в WebAssembly интегрирована в тестовую версию LDCподскажите, разве WebAssembly не бекэнд LLVM? зачем какие-то телодвижения в LDC, который фронтенд LLVM чтоб собрать в бекэнд-WebAssembly?
что конкретно реализовали?
А кто-нибудь сравнивал производительность D и плюсов? Слышал, что ассоциативные массивы в D ощутимо медленнее чем мапы в C++ несколько лет назад
Методику сравнения в студию.
Во-первых, о термине "производительность" следует договориться.Во-вторых, ассоциативные массивы в D --- часть языка, а map<> в C++ --- реализация средствами языка. И, как бы, нет ограниченности единственной реализацией, а можно иметь разные, под разные гарантии, особенности применения и т.п. Т.е. C++ --- мультипарадигменный язык, позволяющий варьировать концепцию разработки, а D --- нет. И поэтому как "системный" язык D никуда не годится, а только как банка с синтаксическим сахаром.
Ассоциативные массивы в D часть языка исключительно синтаксически, насколько я помню альтернативные реализации прекрасно впиливаются. И, что характерно, использовать свою мапу с любыми нравящимися гарантиями ровно как и в плюсах никто не запрещал.
Ну, не хватало ещё, чтобы авторы языка запрещали реализовывать алгоритмы, конкурирующие с конструкциями языка :)
Идем на официальную вики по ссылке, качаем официальный пререлиз с офсайта, делаем как написано в этой свежей, не старой статье и...-d: error: unknown argument: --no-warn-search-mismatch
Error: linking with LLD failedЕще кому-то надо объяснять, почему D все никак не взлетит? Мне - нет.
Я сделал, как в статье, у меня скомпилировалось.
Сделал как в статье, то же что у автора выше:
скачал и распаковал билд,my-pc:~/tmp/wasm$ export PATH=$PATH:/opt/ldc2-1.11.0-beta2-linux-x86_64/bin
my-pc:~/tmp/wasm$ ldc2 -mtriple=wasm32-unknown-unknown-wasm -betterC -link-internally wasm.d
lld: error: unknown argument: --no-warn-search-mismatch
Error: linking with LLD failed
Попробовал воспользоваться штатным инсталлятором (https://dlang.org/install.html), все скачалось и установилось.
Ошибка та же.me@my-pc:~/dlang/ldc-1.11.0-beta2$ . activate
(ldc-1.11.0-beta2)me@my-pc:~/dlang/ldc-1.11.0-beta2$ ldc2 -mtriple=wasm32-unknown-unknown-wasm -betterC -link-internally wasm.d
lld: error: unknown argument: --no-warn-search-mismatch
Error: linking with LLD failedГoвно этот ваш d-lang, если элементарные вещи из коробки не работают. Время только тратить...
Продолжаем развлекатьсяme@my-pc:~/dlang$ ./install.sh install dmd
Downloading and unpacking http://downloads.dlang.org/releases/2.x/2.081.1/dmd.2.081.1....
######################################################################## 100,0%
Invalid signature http://downloads.dlang.org/releases/2.x/2.081.1/dmd.2.081.1....