по сути не использует, это Александреску (соавтор D) осилил написать 5тыс строк, но для чего они - большой секрет, кстати еще и назвиздел, что компилируется быстрее, вероятно код на С++ с бустом был, т.к.:
~$ cat a.d
import std.stdio;
void main()
{
writeln("Hello, world!");
}
~$ cat a.cpp
#include <iostream>
int main() {
std::cout << "Hello, world!\n";
}
~$ cat b.cpp
#include <cstdio>
int main() {
printf("Hello, world!\n");
}
~$ time gdc a.d
real 0m0.166s
user 0m0.143s
sys 0m0.024s
~$ time dmd a.d
real 0m0.220s
user 0m0.183s
sys 0m0.038s
~$ time g++ a.cpp
real 0m0.122s
user 0m0.101s
sys 0m0.021s
~$ time g++ b.cpp
real 0m0.038s
user 0m0.024s
sys 0m0.015s
а на чуть более сложных примерах:
~$ cat a.d
import std.stdio;
struct Fib
{
private:
int _value;
public:
this(int n) { _value = n; }
int value()
{
if(_value <= 2)
return 1;
scope Fib f1 = Fib(_value - 1);
scope Fib f2 = Fib(_value - 2);
return f1.value() + f2.value();
}
};
int main()
{
for (int i = 0; i < 10; i++)
{
scope Fib x = Fib(40);
writefln("n=%d", x.value);
}
return 0;
}
~$ cat a.cpp
#include <stdio.h>
class Fib
{
private:
int _value;
public:
Fib(int n) { _value = n; }
int value()
{
if(_value <= 2)
return 1;
Fib f1 = Fib(_value - 1);
Fib f2 = Fib(_value - 2);
return f1.value() + f2.value();
}
};
int main()
{
for(int i=0; i<10; i++)
{
Fib x = Fib(40);
printf("n=%d\n", x.value());
}
return 0;
}
~$ time gdc a.d
real 0m0.411s
user 0m0.363s
sys 0m0.031s
~$ time dmd a.d
real 0m0.226s
user 0m0.186s
sys 0m0.039s
~$ time g++ a.cpp
real 0m0.053s
user 0m0.037s
sys 0m0.020s
это код Крона отсюда Бенчмарк объектный Фибоначчи. Часть 3-я., кстати последнее обновление в репе gdc таки сделало его пошустрее, но все-равно компиляторы D заметно медленнее g++ (даже не clang или msvc)
А если ли вообще где-нибудь кроме шарпа(в джаве например) аналог linq? Я ни linq поработал и теперь не представляю как писать работу с данными без этого.
кстати последнее обновление в репе gdc таки сделало его пошустрее, но все-равно компиляторы D заметно медленнее g++ (даже не clang или msvc)
Это неудивительно — рулит софт, который разрабатывают, а не тот, фичи которого проработаны только в теории. Но на больших проектах D всё-таки может уйти вперёд за счёт отсутствия #include.
Это же, если я правильно нагуглил, паттерн. К языковым конструкциям отношения не имеет. И «любую» коллекцию из стандартной библиотеки обрабатывать не позволит.
Пилил в прошлом году GSoC-проект на D. Живёт, развивается потихоньку, ~20kLOC, с каждой новой версией компилятора приходится 10-20 строчек фиксить, что не страшно. В общем, для консольных приложений всё вполне сносно.
Производительность на уровне C легко достижима, если не дёргать GC по каждому чиху. Ну и естественно, для релизных сборок нужно использовать LDC/GDC, а не убогий в плане оптимизации DMD.
Это же, если я правильно нагуглил, паттерн. К языковым конструкциям отношения не имеет. И «любую» коллекцию из стандартной библиотеки обрабатывать не позволит.
Вот только с этим паттерном в полной реализации весь код работы с SQL может исчезнуть вообще — а в LINQ он просто становится частью языка, не более.