Здравствуйте, VladD2, Вы писали:
EP>>Да никакой тут магии нет — в "|" столько же магии, сколько и в "<<", а это уже VD>А _1 тоже не магия?
_1 это библиотечная полиморфная лямбда, если считаешь магией — то есть встроенная в язык, но для неё нужно чуть больше закорючек.
VD>Но как замена для плюсов в задачах где нужно битовижимательство вполне потянет.
Чисто как язык — возможно. Но помимо языка нужна платформа — библиотеки, компиляторы, с которыми, afaik, пока не густо.
VD>За фиг нужен статик иф если есть обычный?
Те ветки кода которые отбраковываются — практически не проверяются компилятором.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
DM>>А теперь ты покажи аналог, не требующий forward итератор. EP>Ну так вот же он: EP>Если input range — то возвращается только вторая часть, но во всех остальных — обе. EP>У тебя же .save, который как я понял — даст compile error на single pass.
Именно, D на этапе компиляции уже не даст сделать глупость. В твоем же случае компилятор даже не заикнется, если ты применишь свою функцию на одноразовом итераторе и будешь из результата строить "первую часть", которая уже съедена.
DM>>A такой итератор дает random access? Если нет, то причем тут индексы, а если да, то как он это делает без "опасных" индексов? EP>В смысле? EP>Там где в STL будут два итератора: EP>*x++ = *y++; EP>(move может быть намного сложнее ++).
Вот именно этот момент и интересен для random access. Какой у move аргумент? То же самое целое число? Тогда я не вижу особой разницы.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
VD>>Так что по факту продвижению Ди больше мешают привычки и косность мышления нежели какие-то технические сложности. EP>afaik, как минимум нет быстрого компилятора
Быстрого именно компилятора как раз нет у С++. D компилируется на порядок быстрее. Если же речь о получаемом коде, то есть же GDC и LDC, где codegen'ы из GCC и LLVM соответственно.
Здравствуйте, VladD2, Вы писали: VD>Здравствуйте, Evgeny.Panasyuk, Вы писали: EP>>Вспомни консоль: EP>>cat x | grep y | sort VD>Меня от линуксовой консоли всегда мутило.
Да не вопрос:
DOS/WinXP
http://technet.microsoft.com/en-us/library/ee176927.aspx#EDAA
Так что ни у кого, кроме тебя, operator pipe проблем не вызывает. VD>Как-то объектная точка или функциональный оператор |> понятнее.
"объектная точка или функциональный оператор |>" в С++ — не пришей кобыле хвост. VD>А _1 тоже не магия?
Вообще _1 в стандарте С++11 уже, в std::placeholders — см. 20.8.9.1.4 Placeholders. EP>>Каким именно делом? Где тормозить? VD>Бустом. Или что ты там использовал для получения недолямбд с параметрами _1, _2 и т.п.?
В С++11 и без буста все прекрасно реализуется в три строчки (А в С++14 — в одну). Пример с умножением:
struct Mul {
template<class X, class Y>auto operator()(X x, Y y) -> JUST_RETURN(x*y)
};
template<class X, class Y>auto operator*(X x, Y y) -> JUST_RETURN(bind(Mul(), x, y))
полный код с тестом, обрати особое внимание на последние 2 строчки теста
И что тут должно тормозить, по-твоему? Не будет тут тормозов ни при компиляции (потому что код элементарный), ни при исполнении программы. VD>А критикуете вы его совсем не за то.
Мы его не критикуем, вообще-то.
Никто не говорит, что D хуже С++.
Мы говорим, что то, что он может предложить по сравнению с С++11 (и С++14), недостаточно для того, чтоб все бросились переписывать на нем плюсовые программы или нанимать новых/переобучать имеющихся программеров. Овчинка выделки не стоит.
Здравствуйте, VladD2, Вы писали:
VD>А критикуете вы его совсем не за то. Я бы вот скорее обратил внимание на то что МП в Ди тоже хиленький. Правильный МП должен позволять писать метапрограммы на том же языке что и обычные. В Ди с этим по лучше чем в С++ (где МП надо делать на побочных эффектах от материализации шаблонов), но все же не фирст-класс. За фиг нужен статик иф если есть обычный?
В D как раз вполне себе можно использовать тот же язык как в обычном коде, так и в МП (в компайл-тайме).
auto getNums(int k) // описываем обычную функцию
{
return iota(0,k).filter!(x => x*x % 10 == 1).array;
}
void main(string[] argv)
{
auto runTimeValue = getNums(argv[1].to!int); //вызываем ее в рантайме
writeln(runTimeValue);
enum compileTimeValue = getNums(100); //вызываем ее же в компайл-тайме
writeln(compileTimeValue);
}
Причем обычный код и МП можно писать прямо рядом и вперемежку, нет разделения на стадии, как в более примитивных подходах.
И чтобы можно было при такой записи вперемежку выбирать между рантаймом и компайлтаймом, есть static.
Здравствуйте, D. Mon, Вы писали:
DM>В D как раз вполне себе можно использовать тот же язык как в обычном коде, так и в МП (в компайл-тайме). DM>Причем обычный код и МП можно писать прямо рядом и вперемежку, нет разделения на стадии, как в более примитивных подходах. DM>И чтобы можно было при такой записи вперемежку выбирать между рантаймом и компайлтаймом, есть static.
Твой пример примерно соответствует constexpr-функциям из C++11.
Здравствуйте, VladD2, Вы писали:
VD>Интереснее было бы на более не тривиальные примеры метапрограммирования посмотреть. VD>Вот как будет выглядеть генерация функции считающей hesh code? И как ее применить?
В простом случае, как у тебя:
mixin template ImplementGetSheeshCode() {
size_t GetSheeshCode() // эта функция станет членом класса
{
alias T = typeof(this);
size_t h = 123;
foreach(m; __traits(allMembers, T)) // проходим по полям; такой foreach будет раскрыт, цикла не останетсяstatic if (m!="Monitor") {
static if (isIntegral!(typeof(__traits(getMember, T, m))))
h ^= __traits(getMember, T, m);
else static if (__traits(hasMember, typeof(__traits(getMember, T, m)), "toHash"))
h ^= __traits(getMember, T, m).toHash;
}
return h;
}
}
class A { // используем МП прямо там же, где только что определилиint Field1;
string Field2;
mixin ImplementGetSheeshCode; // не атрибут, но тоже одна строчка
}
void main(string[] argv)
{
auto a = new A;
writeln(a.GetSheeshCode());
}
Здравствуйте, jazzer, Вы писали:
J>Твой пример примерно соответствует constexpr-функциям из C++11.
Только там такие функции нужно перелопатить, расставив везде constexpr, и они сильно ограничены по тому, что в них можно делать. А тут берешь готовый код из стандартной или других библиотек и используешь. Ограничения тоже есть, конечно, но их меньше.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, jazzer, Вы писали:
J>>Твой пример примерно соответствует constexpr-функциям из C++11.
DM>Только там такие функции нужно перелопатить, расставив везде constexpr, и они сильно ограничены по тому, что в них можно делать. А тут берешь готовый код из стандартной или других библиотек и используешь. Ограничения тоже есть, конечно, но их меньше.
Ну так я поэтому и говорю — примерно. Но если у тебя есть функция constexpr — ты ее можешь звать откуда угодно — и во время компиляции, и во время исполнения.
Плюс раз уж мы говорим о "готовом коде из стандартной или других библиотек" — так в С++ сейчас все (в бусте, по крайней мере) стараются по возможности делать свои функции constexpr, так что для юзера то же самое получится — он просто заюзает соответствующую функцию из либы.
Здравствуйте, Кодт, Вы писали:
I>>Покажи реализацию без исключений, особенно return интересует
К>Фигня-война. Если return void, то делается довольно просто.
Для каждого вида АПИ надо писать вот такую пару макросов или переходник, что бы эти макры юзать
По моему это именно то, чего делать не надо — макросы вот такие.
Здравствуйте, Ikemefula, Вы писали:
I>>>Покажи реализацию без исключений, особенно return интересует
К>>Фигня-война. Если return void, то делается довольно просто.
I>Для каждого вида АПИ надо писать вот такую пару макросов или переходник, что бы эти макры юзать I>По моему это именно то, чего делать не надо — макросы вот такие.
Ты просил показать реализацию — я показал. Чисто proof of concept.
Другое дело, что это уродливое решение дурацкой проблемы. "А вот захотелось сделать императивный цикл над гетерогенными данными". А вот зачем он такой нужен?
Здравствуйте, jazzer, Вы писали:
J>Никто не говорит, что D хуже С++. J>Мы говорим, что то, что он может предложить по сравнению с С++11 (и С++14), недостаточно для того, чтоб все бросились переписывать на нем плюсовые программы или нанимать новых/переобучать имеющихся программеров. Овчинка выделки не стоит.
Странный аргумент. Программы на коболе, лиспе, фортране, ассемблере и многих других древних языках так же очень редко переписываются чисто ради "язык сменить". То есть, "бросились переписывать" для любого языке вещь крайне редкая.
Поэтому вопрос не в том, будут ли на D переписывать плюсовый код, а в том будет ли в новых проектах использоваться D и, если будет, то для чего.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, jazzer, Вы писали:
J>>Никто не говорит, что D хуже С++. J>>Мы говорим, что то, что он может предложить по сравнению с С++11 (и С++14), недостаточно для того, чтоб все бросились переписывать на нем плюсовые программы или нанимать новых/переобучать имеющихся программеров. Овчинка выделки не стоит.
I>Странный аргумент. Программы на коболе, лиспе, фортране, ассемблере и многих других древних языках так же очень редко переписываются чисто ради "язык сменить". То есть, "бросились переписывать" для любого языке вещь крайне редкая.
I>Поэтому вопрос не в том, будут ли на D переписывать плюсовый код, а в том будет ли в новых проектах использоваться D и, если будет, то для чего.
Для новых проектов на новых языках нужны новые программисты. А такое счастье никому не нужно. Чтоб вложиться в это, выгоды от нового языка должны быть очень большими.
Здравствуйте, jazzer, Вы писали:
I>>Поэтому вопрос не в том, будут ли на D переписывать плюсовый код, а в том будет ли в новых проектах использоваться D и, если будет, то для чего.
J>Для новых проектов на новых языках нужны новые программисты. А такое счастье никому не нужно. Чтоб вложиться в это, выгоды от нового языка должны быть очень большими.
Да ладно, откуда например берутся проекты на хаскеле, на руби+рельсах, на go, на clojure? Чаще всего в уже существующих компаниях конкретные программисты настолько вдохновляются каким-то языком, что всячески пытаются его использовать. Когда им разрешают (или не мешают), получаются проекты на этих языках. Иногда новые, иногда переписанные старые. Так что нужен лишь энтузиазм и отстутствие непреодолимых проблем в языке/реализации.
Здравствуйте, jazzer, Вы писали:
I>>Поэтому вопрос не в том, будут ли на D переписывать плюсовый код, а в том будет ли в новых проектах использоваться D и, если будет, то для чего.
J>Для новых проектов на новых языках нужны новые программисты. А такое счастье никому не нужно. Чтоб вложиться в это, выгоды от нового языка должны быть очень большими.
Не новые, а уже имеющиеся и для начала этого хватит. В свое время сиплюсники переходили и на джаву, и на дотнет и каких то проблем не вызвало. Вот будут ли выгодны от D — вот это и хочется узнать.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, jazzer, Вы писали:
I>>>Поэтому вопрос не в том, будут ли на D переписывать плюсовый код, а в том будет ли в новых проектах использоваться D и, если будет, то для чего.
J>>Для новых проектов на новых языках нужны новые программисты. А такое счастье никому не нужно. Чтоб вложиться в это, выгоды от нового языка должны быть очень большими.
I>Не новые, а уже имеющиеся и для начала этого хватит. В свое время сиплюсники переходили и на джаву, и на дотнет и каких то проблем не вызвало. Вот будут ли выгодны от D — вот это и хочется узнать.
Они туда переходили, потому что была мощнейшая финансовая поддержка со стороны Сана и Мелкософта (кстати, интересно, во сколько им обошелся весь евангелизм и разработка? Кому-нть попадались цифры?). Если Фейсбук вдруг обеспечит такую же мощную поддержку D — может, и взлетит тогда. Но я в этом сомневаюсь — Фейсбуку, в отличие от Мелкософта, никакой выгоды от D нет — Фейсбук не стрижет деньги ни со Студии, ни с Винды, на которой дотнет крутится. Так что вложенные в раскрутку деньги никак не окупятся.
Вот Немерле — замечательный язык — и что? И где он? В 5 с половиной проектах на весь мир? И таких Немерлей — море. У них у всех есть какие-нть преимущества перед имеющимися. Причем реальные преимущества. Но их недостаточно — киллер-фичи нет. А если есть — так скорее мейнстримные языки эту фичу в себя в каком-то виде втянут (что мы все наблюдаем на примере функциональщины и DSL-ей), чем народ все бросит и дружно перейдет на маргинальный язык.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, jazzer, Вы писали:
I>>>Поэтому вопрос не в том, будут ли на D переписывать плюсовый код, а в том будет ли в новых проектах использоваться D и, если будет, то для чего.
J>>Для новых проектов на новых языках нужны новые программисты. А такое счастье никому не нужно. Чтоб вложиться в это, выгоды от нового языка должны быть очень большими.
DM>Да ладно, откуда например берутся проекты на хаскеле, на руби+рельсах, на go, на clojure? Чаще всего в уже существующих компаниях конкретные программисты настолько вдохновляются каким-то языком, что всячески пытаются его использовать. Когда им разрешают (или не мешают), получаются проекты на этих языках. Иногда новые, иногда переписанные старые. Так что нужен лишь энтузиазм и отстутствие непреодолимых проблем в языке/реализации.
Я и говорю — нужен евангелизм, причем масштабный (т.е. недешевый), если хочется, чтоб случился массовый исход, как в жабу/дотнет. А на голом энтузиазме все таки и будет на уровне стартапов (там хоть на брейнфаке можно писать) и недосмотра (или лапши на ушах) менеджеров — потому что ни один бизнес в здравом уме не подпишется на использование языка, который на 5% (ну хорошо, на 10%) лучше имеющегося, не имея достаточного притока программеров с рынка, достаточной стабильности самого языка (чем D никак не может похвастаться), богатства инфраструктуры, ресурсов в инете, курсов по обучению и повышению квалификации, книжек и прочая и прочая и прочая. То есть того, во что Сан и МС вбухали немалые деньги.
Пример Яху всем известен, правда? Пара маргиналов написали систему на маргинальном языке (лиспе) и свалили. Яху помучилась-помучилась и переписала все на мейнстримовом языке.
Пример Немерле тоже у всех перед глазами — как был маргинальным, так и остается, несмотря на обещания о скором захвате мира.
Здравствуйте, D. Mon, Вы писали:
DM>>>А теперь ты покажи аналог, не требующий forward итератор. EP>>Ну так вот же он: EP>>Если input range — то возвращается только вторая часть, но во всех остальных — обе. EP>>У тебя же .save, который как я понял — даст compile error на single pass. DM>Именно, D на этапе компиляции уже не даст сделать глупость.
Какую? Найти позицию элемента в single pass range это глупость? Интересный подход.
DM>В твоем же случае компилятор даже не заикнется, если ты применишь свою функцию на одноразовом итераторе и будешь из результата строить "первую часть", которая уже съедена.
Да нет в этом ничего страшного. Когда ты одеваешь смирительную рубашку — она часто запрещает тебе делать и опасные и полезные действия.
"Отрицательные числа позволяют делать очень плохие вещи когда у нас есть квадратный корень. Давайте решим проблему с квадратным корнем, тем что запретим отрицательные числа" (68:23)
Плохих же программистов никакие рубашки не остановят — они очень находчивые.
Ограничить себя в чём-то всегда можно успеть, безопасность это всё лирика, а вот ты всё-таки попробуй сделать полноценный аналог.
DM>Вот именно этот момент и интересен для random access. Какой у move аргумент? То же самое целое число? Тогда я не вижу особой разницы.
Если будет число, то оно появится и в случае с range.
// 5 entities:
w += n;
z += n/2;
x[w] = y[z];
// versus 3 entities:
x += n;
y += n/2;
*x = *y;
Здравствуйте, D. Mon, Вы писали:
DM>Если же речь о получаемом коде, то есть же GDC и LDC, где codegen'ы из GCC и LLVM соответственно.
Если они стабильно работают, поддерживают последнюю версию языка, и при этом генерируют код не хуже C++ компиляторов — то это действительно было бы круто.