Примеры для mercury выглядят элегантно, но, конечно, это простые демки. У вайба, как у большого проекта, появился один недостаток — там черт ногу сломит разбираться во многокилометровых модулях. Вот mercury хорошо демонструет ядро асинхронного IO.
Ух ты, наконец-то оформили в отдельную страничку то, что приходилось собирать по новостной группе.
Итого вы работаете с vibe.d? Сопрограммы, правда, я там не видел в чистом виде. Я его использую для синхронизации рукописных кешей для бд, очень уж удобно устроен rest-api. Также все приглядываюсь к SCTP, если реализовать его сокеты для vibe.d, то можно будет не велосипедить на UDP стриминг голоса/видео и игровых данных.
Ожидал увидеть еще рекомендации по написанию bindings, местами бывают нетривиальные или неочевидные проблемы. Как например, глобальные переменные должны экспортированы вот так:
Пока на написание такого труда я не готов. Из уже имеющихся книг могу порекомендовать:
1. D Cookbook — свежее собрание приемов, специфичных для D.
2. The D Programming Language (перевод), написана в 2010, поэтому многие примеры могут без пинка не заработать.
Логика такова: если функцию вызывать в контексте, когда она может быть выполнена только в compile-time, то она гарантированно выполнится в compile-time.
Т.е.:
int res = X(some_var); // run-time
auto res = X(some_var); // run-time
enum res = X(some_var); // compile-time only
immutable res = X(some_var); // compile-time или run-time, если не может выполниться в compile-time
static res = X(some_var); // compile-time или run-time, если не может выполниться в compile-time
А явно указать какие функции inline, какие нет — нельзя. Оптимизатор сам решает этот момент. Помню у GDC была специальная pragma для forceinline, но в общем случае такой фичи нет.
Такое утверждение я видел в период перехода с D1 на D2, тогда, да, было обоснованно. Сейчас это хорошо продуманный язык с удобной стандартной библиотекой. Можно на нем писать как на Java или Python и никогда не опускаться на системный уровень. Учитывая очень быструю компиляцию, я уже давно использую D в скриптах.
Можно передавать как аргументы шаблона все что угодно (что можно посчитать в compile-time): POD типы, лямбды, функции, классы, структуры, шаблоны, и даже целиком expressions.
Аргумент — кастомный класс:
import std.stdio;
class A
{
string field = "Hello";
}
class B(T)
{
T sub = new T();
}
void main()
{
auto b = new B!A();
writeln(b.sub.field);
}
Автор оригинала пытался охватить еще и новичков. Пока получается слишком verbose, но далее должно пойти интереснее, так как будут рассматриваться неочевидные моменты.
Может быть сделать кусочный перевод и пропустить совсем уж начальный материал?
Проверил на ~master (v2.066-devel-e3bada6) — тоже все нормально.
P.S. Грабли: array.clear; не очищает мапу, а вызывает alias для object.destroy. В 2.066 alias стал deprecated. Чтобы очистить мапу можно либо присвоить ей свежесозданную или пройтись по всем ключам и удалить их.
Так точно, в обоих случаях изменения будут видны вне функции, разницы нет. Я привел пример с add2 только для демонстрации тонкости того, что ассоциативные массивы всегда передаются по ссылке.
Если ассоциативные массивы копировались бы при передаче в функцию, то последний writeln вывел ["o":2], изменялся бы локальный ассоциативный массив внутри функции. Такое поведение имеют статические массивы:
Если для статических массивов нужно ссылочное поведение, то к типу аргумента добавляют ref. Также важный момент add(array[]), через оператор [ ] (оператор для slicing) мы получаем динамический массив, который внутри ссылается на данные статического массива.
В D ассоциативные массивы встроены в рантайм и полагаются на GC. Реализованы они как объекты, т.е. чтобы освободить память ассоциативного массива нужно обнулить все ссылки на него, а также можно вызывать метод clear для очистки внутренностей а.массива.
Итого вы работаете с vibe.d? Сопрограммы, правда, я там не видел в чистом виде. Я его использую для синхронизации рукописных кешей для бд, очень уж удобно устроен rest-api. Также все приглядываюсь к SCTP, если реализовать его сокеты для vibe.d, то можно будет не велосипедить на UDP стриминг голоса/видео и игровых данных.
1. D Cookbook — свежее собрание приемов, специфичных для D.
2. The D Programming Language (перевод), написана в 2010, поэтому многие примеры могут без пинка не заработать.
Т.е.:
А явно указать какие функции inline, какие нет — нельзя. Оптимизатор сам решает этот момент. Помню у GDC была специальная pragma для forceinline, но в общем случае такой фичи нет.
Аргумент — кастомный класс:
Да, хорошая идея, пост о средствах метапрограммирования в D + небольшое сравнение с constexpr и выводом типов (оно различается с C++14).
Может быть сделать кусочный перевод и пропустить совсем уж начальный материал?
P.S. Грабли:
array.clear;
не очищает мапу, а вызывает alias для object.destroy. В 2.066 alias стал deprecated. Чтобы очистить мапу можно либо присвоить ей свежесозданную или пройтись по всем ключам и удалить их.add2
только для демонстрации тонкости того, что ассоциативные массивы всегда передаются по ссылке.["o":2]
, изменялся бы локальный ассоциативный массив внутри функции. Такое поведение имеют статические массивы:Если для статических массивов нужно ссылочное поведение, то к типу аргумента добавляют ref. Также важный момент
add(array[])
, через оператор [ ] (оператор для slicing) мы получаем динамический массив, который внутри ссылается на данные статического массива.Проблем с GC быть не должно, если ссылок на ассоциативны массив больше нет, то он удаляется.
Для хеширования используется TypeInfo (TypeInfo для классов переопределяет поведение getHash), соответственно:
время сек: 9.19
память: 564
Все файлы, относящиеся к бенчмарку D лежат на гитхабе.
DMD:
GDC (один из последних коммитов):
LDC2:
Замерял следующим образом (далее таблица по 10 замеров для каждого билда):
Таблица замеров (время в секундах):
Выводы: Rust и D примерно одинаковы по производительности. Для D лучше использовать GDC, когда важна скорость.
Конфигурация машины:
Intel® Core(TM)2 Quad CPU Q9400 @ 2.66GHz
3.14.4-200.fc20.x86_64