Еще добавлю: есть разница между «статическое вычисление обеспечено стандартом языка» и «понадеемся, что компилятор сообразит, что выражение можно вычислить статически».
Это возможно заилайнить. Но если там будет не лямбда в явном виде, а какой-нибудь указатель на функцию, то уже нельзя. Ну или сложно — вдруг кто-то этот указатель переприсвоил другой функции в рантайме? А в D полностью статическое вычисление обеспечено языком.
Это пожелание к статье или вопрос про язык?
Если второе, то да, насколько я знаю, во всех языках в си подобным синтаксисом можно дробить выражения на несколько строк, а если первое, то не уверен, что будет сильно лучше.
Вот как раз я начал размышлять, что лучше в третей статье написать: тонкости функционального или обьектно-ориентированного подхода. Потому, что и там и там много интересных возможностей, и выбрать как-то сложно.
Подписываюсь под каждым словом. Кроме несбыточнотсти. Гугл вообще проявил тенденции к внедрению инноваций и покупке кучи компаний. Так что кто знает. Да и не гуглом единым. Так что будем надеяться.
1) [=], [&] и то и другое, несомненно, отвратительно: большие обьекты при [=] будут тормозить + вдруг надо именно по ссылке, а встроенные типы при [&] могет нежелательно себя вести. Вы совершенно правы, что управляете процессом вручную. Вот только в D в данном случае Explicit equal to implicit. Об этом я еще расскажу, несомненно.
2) Да, я надеялся, что аудитории понравится и я смогу продолжить цикл и описать целую кучу особенностей, которые сами по себе вроде как довольно милые, но сильно не впечатляют, но учитывая, что их очень много, экономия кода и времени его написания получается внушительная. Про время я пока сужу субьективно, так как больших проектов не писал, но оно как минимум пропорционально количеству кода.
Да, верно.
И нет, не верно, это не термин, это я попытался описать явление необходимости заново писать конструктор с параметроми в классе-потомке. Может, неудачно, но уж как получилось.
Верно, лямбды создаются уже и в C++.
Однако, во-первых они не так хороши. Ваше [] на самом деле почти всегда (если это делегат) совсем даже не [], а сложным выражением, выбирающим какие переменные и как туда послать. А если их много?
Во-вторых может это мой личный вкус, но std::function<int(int)> — это, конечно, хорошо, а что, если она вектор строк возвращает? Макароны получаются. Или много typedef. Замечу, что да, auto спасает, но работает оно не везде и не для всех типов.
Попробуйте, например, написать такой код:
int[string] function(int[string]) getFun()
{
return (int[string] a) {return a ~= ["hi" : 1];};
}
Но это все, конечно, житейские мелочи, глобально я полностью согласен, что новый стандарт неплохо улучшил язык.
Однако лямбды — далеко не все, что я описал в статье и тем более, далеко не все, чем отличается C++ от D.
Все пишут про нехватку инструментов для программирования.
Согласен, их меньше, чем для некоторых других языков, однако не все так ужасно.
Вообще-то я хотел в следующей статье обсудить другие темы, но если коммьюнити желает — могу подробно описать все, что знаю (и еще нагуглю) по этому поводу. Заранее скажу, я программирую на D только пару недель, однако нехватки инструментария не ощущаю.
Я не изучал эту сторону вопроса, но вот последний (первый в списке, последний по времени) пункт changelog:
Better use of XMM registers in 64 bit targets.
Так что поддержка, несомненно, есть.
Может и правда не идеальная, но есть. И развивается.
Сдается мне, вы меня не поняли, а может я вас.
Уверен, так будет понятней:
import std.stdio;
class A
{
this() {writeln("A");}
~this() {writeln("~A");}
}
class B : A
{
this() {writeln("B");}
~this() {writeln("~B");}
}
void main()
{
B b = new B;
clear(b);
}
Выводит:
A
B
~B
~A
Как и аналогичная программа на C++.
Однако, программа:
import std.stdio;
class A
{
string s;
this() { s = ""; }
this(string s) { this.s = s; }
}
class B : A
{
override string toString() { return "trollface"; }
}
void main()
{
B a = new B("hi!");
}
Не компилируется потому, что вместо B. this(string s) не подставляется A.this(string).
Если второе, то да, насколько я знаю, во всех языках в си подобным синтаксисом можно дробить выражения на несколько строк, а если первое, то не уверен, что будет сильно лучше.
Да если я буду в профиль писать все, что мне нравится, он же ух как раздуется!
2) Да, я надеялся, что аудитории понравится и я смогу продолжить цикл и описать целую кучу особенностей, которые сами по себе вроде как довольно милые, но сильно не впечатляют, но учитывая, что их очень много, экономия кода и времени его написания получается внушительная. Про время я пока сужу субьективно, так как больших проектов не писал, но оно как минимум пропорционально количеству кода.
И нет, не верно, это не термин, это я попытался описать явление необходимости заново писать конструктор с параметроми в классе-потомке. Может, неудачно, но уж как получилось.
Однако, во-первых они не так хороши. Ваше [] на самом деле почти всегда (если это делегат) совсем даже не [], а сложным выражением, выбирающим какие переменные и как туда послать. А если их много?
Во-вторых может это мой личный вкус, но std::function<int(int)> — это, конечно, хорошо, а что, если она вектор строк возвращает? Макароны получаются. Или много typedef. Замечу, что да, auto спасает, но работает оно не везде и не для всех типов.
Попробуйте, например, написать такой код:
Но это все, конечно, житейские мелочи, глобально я полностью согласен, что новый стандарт неплохо улучшил язык.
Однако лямбды — далеко не все, что я описал в статье и тем более, далеко не все, чем отличается C++ от D.
Согласен, их меньше, чем для некоторых других языков, однако не все так ужасно.
Вообще-то я хотел в следующей статье обсудить другие темы, но если коммьюнити желает — могу подробно описать все, что знаю (и еще нагуглю) по этому поводу. Заранее скажу, я программирую на D только пару недель, однако нехватки инструментария не ощущаю.
Better use of XMM registers in 64 bit targets.
Так что поддержка, несомненно, есть.
Может и правда не идеальная, но есть. И развивается.
Уверен, так будет понятней:
Выводит:
A
B
~B
~A
Как и аналогичная программа на C++.
Однако, программа:
Не компилируется потому, что вместо B. this(string s) не подставляется A.this(string).