Здравствуйте, jazzer, Вы писали:

EP>>>Вспомни консоль:
EP>>>cat x | grep y | sort
VD>>Меня от линуксовой консоли всегда мутило.
J>Да не вопрос:
J>DOS/WinXP

И про консоль, и про имена — это всё придирки к мелочам.

J>В С++11 и без буста все прекрасно реализуется в три строчки (А в С++14 — в одну).

Причём в C++14 добавилось несколько способов — transparent operator functors и само-собой п.лямбды.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

DM>>Если же речь о получаемом коде, то есть же GDC и LDC, где codegen'ы из GCC и LLVM соответственно.

EP>Если они стабильно работают, поддерживают последнюю версию языка, и при этом генерируют код не хуже C++ компиляторов — то это действительно было бы круто.

Да, вот, например, свежачок:
https://github.com/ldc-developers/ldc/releases/tag/v0.12.0
Последняя версия языка плюс довольно свежий LLVM.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

DM>>>>А теперь ты покажи аналог, не требующий forward итератор.
EP>>>Ну так вот же он:
EP>>>Если input range — то возвращается только вторая часть, но во всех остальных — обе.
EP>>>У тебя же .save, который как я понял — даст compile error на single pass.
DM>>Именно, D на этапе компиляции уже не даст сделать глупость.

EP>Какую? Найти позицию элемента в single pass range это глупость? Интересный подход.

Ты же все приставал с получением двух частей — до найденного элемента и от него дальше. Я показал. Ты попросил завел речь про forward iterator. Я и говорю, что для него получение первой части смысла не имеет, это ошибка, и D ее ловит системой типов.

Здравствуйте, jazzer, Вы писали:

J>Они туда переходили, потому что была мощнейшая финансовая поддержка со стороны Сана и Мелкософта (кстати, интересно, во сколько им обошелся весь евангелизм и разработка? Кому-нть попадались цифры?).

Про джаву ходит фольклор, что в нее Сан миллиард вбухал. Тот же А.А. такую цифру называл.
С другой стороны, в какой-нибудь Руби никто много денег не вкладывал, а свою порцию популярности он получил, и даже гитхаб на рельсах написан был.

Здравствуйте, D. Mon, Вы писали:

EP>>>>У тебя же .save, который как я понял — даст compile error на single pass.
DM>>>Именно, D на этапе компиляции уже не даст сделать глупость.
EP>>Какую? Найти позицию элемента в single pass range это глупость? Интересный подход.
DM>Ты же все приставал с получением двух частей — до найденного элемента и от него дальше. Я показал.

Ну да, показал — неэффективное, негибкое, и более многословное:

auto myfind(Range, T)(Range r, T t)
{
    size_t n = 0;
    auto left = r.save;
    while(!r.empty && r.front != t) {
        r.popFront();
        n++;
    }
    return tuple(left.takeExactly(n), r);
}
// versus
template<typename I, typename T>
I find(I first, I last, const T& x)
{
    while(first != last && *first != x)
        ++first;
    return first;
}

И это всего лишь примитивный линейный поиск А вот что будет, например, с бинарным а-ля std::partition_point?

DM>Ты попросил завел речь про forward iterator. Я и говорю, что для него получение первой части смысла не имеет

Для forward как раз имеет смысл.

DM>это ошибка, и D ее ловит системой типов.

Для single pass range он запрещает и получение первой части и второй — вторая часть вполне легальна

Здравствуйте, FR, Вы писали:

FR>D'шный range не пара итераторов.
FR>Это весьма абстрактная вещь, минимально и достаточно для (односвязного) списка это:
FR>

FR>interface OnePassRange {
FR>   bool empty();
FR>   Ref<T> front();
FR>   void popFront();
FR>}
FR>

хорошо, и как, например, написать функцию, которая вернёт поддиапазон этого диапазона, от начала и до чего-нибудь, ну там элемента с таким-то значением, или, например, "первые пять"?..

Здравствуйте, Evgeny.Panasyuk, Вы писали:


DM>>Ты же все приставал с получением двух частей — до найденного элемента и от него дальше. Я показал.

EP>Ну да, показал — неэффективное, негибкое, и более многословное:

Реально же ерундой занимаетесь, сравниваете мягкое с зеленым.
Итераторы C++ и интервалы D слишком различны. Базовое различие все, включая и
меня, совсем упустили, интервалы D в отличии от итераторов не работают по месту,
а выдают новый интервал, по сути ближе к базовым ФВП из функциональщины
работающими со списками. Даже boost::range в основной массе этого не делает
а тоже работает по месту как и его базовые итераторы.
Из этого и вытекает и легкая комбинируемость и сложность написания примитивов
похожие проблемы есть и в реализациях перечислений для других языков, например
в окамловском BatEnum, в случае D еще и углубленная, как не странно, тягой к
максимальной производительности.
Намного проще, тоже кстати, реализация получается если в языке есть yield.

Здравствуйте, Erop, Вы писали:

E>хорошо, и как, например, написать функцию, которая вернёт поддиапазон этого диапазона, от начала и до чего-нибудь, ну там элемента с таким-то значением, или, например, "первые пять"?..

Так же как вернуть такой же диапазон для C++ input iterator, то есть никак и бессмысленно.
вообще смотри сюда

Автор: FR
Дата: 24.10.13

Здравствуйте, VladD2, Вы писали:


VD>Я с тобой почти согласен, но вообще-то ты сравнил частный случай для которого у D есть готовое решение.

VD>Интереснее было бы на более не тривиальные примеры метапрограммирования посмотреть.

Уже показали, но похоже людям интереснее обсуждение "итераторы от Степанова против интервалов
от Александреску", притом что оба реализуются при желании одинаково и на C++ и на D.

Здравствуйте, FR, Вы писали:

DM>>>Ты же все приставал с получением двух частей — до найденного элемента и от него дальше. Я показал.
EP>>Ну да, показал — неэффективное, негибкое, и более многословное:
FR>Реально же ерундой занимаетесь, сравниваете мягкое с зеленым.
FR>Итераторы C++ и интервалы D слишком различны.

Boost.Range даёт многие преимущества D-style range, не внося их недостатки

FR>Базовое различие все, включая и
FR>меня, совсем упустили, интервалы D в отличии от итераторов не работают по месту,
FR>а выдают новый интервал,

Что значит не по месту? В смысле ленивость? Так эта ленивости доступна и Boost.Range, да и вообще в самих итераторах (а-ля transformed iterator)

FR>по сути ближе к базовым ФВП из функциональщины
FR>работающими со списками.

Подробнее.

FR>Даже boost::range в основной массе этого не делает
FR>а тоже работает по месту как и его базовые итераторы.

Что значит работает по месту?

FR>Намного проще, тоже кстати, реализация получается если в языке есть yield.

yield действительно помогает генерировать ленивые последовательности. Но у него огромный минус — такие последовательности являются примитивным single pass'ом, который приводит к излишним копиям.
Да и вообще, как я говорил ранее:

EP>По факту D Range нормально подходит только для SinglePass.

для всего остального и неудобно и неэффективно.

Здравствуйте, jazzer, Вы писали:

J>Твой пример примерно соответствует constexpr-функциям из C++11.

constexpr из C++11 по сравнению с D'шными вообще ничто, в C++14 да будет гораздо лучше,
уже вполне полезная вещь, но все еще слабее D'шных.

Здравствуйте, Ikemefula, Вы писали:

I>Поэтому вопрос не в том, будут ли на D переписывать плюсовый код, а в том будет ли в новых проектах использоваться D и, если будет, то для чего.

Я скорее уже сильно скептически отношусь к тому что D хоть как-то приблизится к мейнстриму.
Правда я пока, в отличии от хорошо известного тебе, Евгения полностью в нем не разочаровался, все-таки язык хороший.

Здравствуйте, FR, Вы писали:

VD>>Я с тобой почти согласен, но вообще-то ты сравнил частный случай для которого у D есть готовое решение.
VD>>Интереснее было бы на более не тривиальные примеры метапрограммирования посмотреть.
FR>Уже показали, но похоже людям интереснее обсуждение "итераторы от Степанова против интервалов
FR>от Александреску",

А что не так? Нормальное обсуждение стандартной алгоритмической библиотеки одного языка — против библиотеки другого.
Такие библиотеки используются в 99% программ, и вполне заслуживают обсуждения в контексте сравнения языков как платформ в целом, а не просто language feature vs feature.

Если ты согласен с тем что STL итераторы удобней, эффективней и мощнее D-style range — то можем прекратить обсуждение. Если есть какие-то аргументы против этого — то мне интересно будет их услышать.

FR>притом что оба реализуются при желании одинаково и на C++ и на D.

С этим-то вроде никто и не спорит
До определённой степени STL можно реализовать, например, на C#-е (разумеется с overhead'ом, но речь не о нём). Но вот как наши C#-коллеги не пытались найти аналог std::deque, дальше попыток продать двусвязный список или дерево под видом деки дело не пошло

Здравствуйте, Evgeny.Panasyuk, Вы писали:


EP>Boost.Range даёт многие преимущества D-style range, не внося их недостатки

Boost.Range да отличная вещь, избавляет от этих страшных .begin() .end(), но это только
обертка в основном, а если перестает быть оберткой вылезают те же проблемы.

FR>>Базовое различие все, включая и
FR>>меня, совсем упустили, интервалы D в отличии от итераторов не работают по месту,
FR>>а выдают новый интервал,

EP>Что значит не по месту? В смысле ленивость? Так эта ленивости доступна и Boost.Range, да и вообще в самих итераторах (а-ля transformed iterator)

То что большинство функций работающие с D'шными интервалами выдают новый интервал, а не меняют
старый, в отличии от C++ итераторов и Boost.Range. И сравнивать их производительность бессмысленно.
В Boost.Range да это тоже возможно, но реализация будет очень близка к реализации в D.

FR>>по сути ближе к базовым ФВП из функциональщины
FR>>работающими со списками.

EP>Подробнее.

Близка неизменяемостью источника. Тот же BatEnum можешь посмотреть.

FR>>Даже boost::range в основной массе этого не делает
FR>>а тоже работает по месту как и его базовые итераторы.

EP>Что значит работает по месту?

Меняет например контейнер из которого получен интервал а не выдает новый (или ленивый новый).

FR>>Намного проще, тоже кстати, реализация получается если в языке есть yield.

EP>yield действительно помогает генерировать ленивые последовательности. Но у него огромный минус — такие последовательности являются примитивным single pass'ом, который приводит к излишним копиям.

Угу и огромный плюс вытекающий из этого минуса легкая комбинируемость.

EP>Да и вообще, как я говорил ранее:
EP>

EP>>По факту D Range нормально подходит только для SinglePass.

EP>для всего остального и неудобно и неэффективно.

Не согласен, но согласен с тем что реализация примитивов сильно усложняется.

Здравствуйте, FR, Вы писали:

FR>Так же как вернуть такой же диапазон для C++ input iterator, то есть никак и бессмысленно.

Почему это, для односвязного списка, например, о котором была речь, это бессмысленно?

Здравствуйте, FR, Вы писали:

EP>>Boost.Range даёт многие преимущества D-style range, не внося их недостатки
FR>Boost.Range да отличная вещь, избавляет от этих страшных .begin() .end(), но это только
FR>обертка в основном, а если перестает быть оберткой вылезают те же проблемы.

Так наоборот здорово. Когда нужно делать различные манипуляторы с итераторами — всегда есть такая возможность. Зачем себя в этом ограничивать?

FR>>>Базовое различие все, включая и
FR>>>меня, совсем упустили, интервалы D в отличии от итераторов не работают по месту,
FR>>>а выдают новый интервал,
EP>>Что значит не по месту? В смысле ленивость? Так эта ленивости доступна и Boost.Range, да и вообще в самих итераторах (а-ля transformed iterator)
FR>То что большинство функций работающие с D'шными интервалами выдают новый интервал, а не меняют
FR>старый, в отличии от C++ итераторов и Boost.Range. И сравнивать их производительность бессмысленно.
FR>В Boost.Range да это тоже возможно, но реализация будет очень близка к реализации в D.

Так Boost.Range не заставляет менять исходный интервал. Контейнер вообще может быть константным — и быть пропущенным через | transformed(...) | filtered(...) и т.п — всё также лениво

FR>>>Даже boost::range в основной массе этого не делает
FR>>>а тоже работает по месту как и его базовые итераторы
EP>>Что значит работает по месту?
FR>Меняет например контейнер из которого получен интервал а не выдает новый (или ленивый новый).

transformed iterator не меняет контейнер из которого получен интервал

FR>>>Намного проще, тоже кстати, реализация получается если в языке есть yield.

EP>>yield действительно помогает генерировать ленивые последовательности. Но у него огромный минус — такие последовательности являются примитивным single pass'ом, который приводит к излишним копиям.
FR>Угу и огромный плюс вытекающий из этого минуса легкая комбинируемость.

Вот выше показывали map/transformed — ты бы как его реализовал? Как range или через yield?

EP>>Да и вообще, как я говорил ранее:
EP>>

EP>>>По факту D Range нормально подходит только для SinglePass.

EP>>для всего остального и неудобно и неэффективно.
FR>Не согласен,

Выше были примеры — std::partition, std::find. Если мало — попробуй сделать аналог std::partition_point.

FR>но согласен с тем что реализация примитивов сильно усложняется.

Интересно получается — лёгкость реализации примитивов рекламировалась как одна из особенностей D-style range

Здравствуйте, Erop, Вы писали:

FR>>Так же как вернуть такой же диапазон для C++ input iterator, то есть никак и бессмысленно.
E>Почему это, для односвязного списка, например, о котором была речь, это бессмысленно?

У односвязного списка — forward iterator. Я думаю ты его имел ввиду:

E>хорошо, и как, например, написать функцию, которая вернёт поддиапазон этого диапазона, от начала и до чего-нибудь, ну там элемента с таким-то значением, или, например, "первые пять"?..

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>А что не так? Нормальное обсуждение стандартной алгоритмической библиотеки одного языка — против библиотеки другого.

В зациклености на этом.
Это конечно намного проще чем скажем попытатся реализовать на C++ задачку от Влада

Автор: VladD2
Дата: 24.10.13

например.

EP>Такие библиотеки используются в 99% программ, и вполне заслуживают обсуждения в контексте сравнения языков как платформ в целом, а не просто language feature vs feature.

В этом контексте надо учитывать и то что D скажем старается хорошо поддерживать иммутабельность и
параллельность и именно это может быть одной из причин выбора менее эффективных чем итераторы
интервалов.

EP>Если ты согласен с тем что STL итераторы удобней, эффективней и мощнее D-style range — то можем прекратить обсуждение. Если есть какие-то аргументы против этого — то мне интересно будет их услышать.

STL итераторы жутко неудобны: нужно использовать пары везде,
даже там где бессмысленны одиночные, практически не комбинируются.
Опасны в использовании могут легко протухнуть, можно перепутать от разных контейнеров,
запросто уйти за пределы итерирования.
(Просвещать меня про отладочный режим, внимательное кодирование и boost.range не надо).

Да очень эффективны, так как работают по месту и часто являются тончайшей оберткой над указателем.
Что имеешь в виду под "мощнее" я не понял.

Здравствуйте, FR, Вы писали:

FR>Уже показали,

Где?

FR>но похоже людям интереснее обсуждение "итераторы от Степанова против интервалов
FR>от Александреску", притом что оба реализуются при желании одинаково и на C++ и на D.

+1

Сам уровень обсуждаемых проблем просто "радует". Изученные языки явно влияют на людей.

Здравствуйте, FR, Вы писали:

EP>>А что не так? Нормальное обсуждение стандартной алгоритмической библиотеки одного языка — против библиотеки другого.
FR>В зациклености на этом.

Да это не зацикленность — это просто отдельная ветка.

FR>Это конечно намного проще чем скажем попытатся реализовать на C++ задачку от Влада

Автор: VladD2
Дата: 24.10.13

например.

В С++ пока нет compile-time reflection, без этого пробежка по членам в той или иной степени потребует дублирования (которое можно спрятать макросами), или перехода от структур к чему-то более абстрактному типа boost::fusion::map.
Например с помощью чего-то типа BOOST_FUSION_DEFINE_STRUCT + boost::fusion::fold:

template<typename Struct>
size_t hash(const Struct &x)
{
    return boost::fusion::fold(x, size_t(0), [](auto hash, auto z){ return hash_combine_f(hash, z); });
}

Никто не спорит с тем, что хорошо бы было иметь compile-time reflection

EP>>Такие библиотеки используются в 99% программ, и вполне заслуживают обсуждения в контексте сравнения языков как платформ в целом, а не просто language feature vs feature.
FR>В этом контексте надо учитывать и то что D скажем старается хорошо поддерживать иммутабельность и
FR>параллельность и именно это может быть одной из причин выбора менее эффективных чем итераторы
FR>интервалов.

Нет. D-style range'и не добавляют ни параллельности, ни иммутабельности.

EP>>Если ты согласен с тем что STL итераторы удобней, эффективней и мощнее D-style range — то можем прекратить обсуждение. Если есть какие-то аргументы против этого — то мне интересно будет их услышать.
FR>STL итераторы жутко неудобны: нужно использовать пары везде,
FR>даже там где бессмысленны одиночные, практически не комбинируются.
FR>Опасны в использовании могут легко протухнуть, можно перепутать от разных контейнеров,
FR>запросто уйти за пределы итерирования.
FR>(Просвещать меня про отладочный режим, внимательное кодирование и boost.range не надо).

Почему не надо? Итераторы не запрещают удобных обёрток, Boost.Range тому пример (+ такие range будут в будущем стандарте).
А вот из D-style range — итераторов уже не вытащить

FR>Да очень эффективны, так как работают по месту и часто являются тончайшей оберткой над указателем.

Дело не только в этом — range также может быть обвёрткой над двумя указателями. Но смотри к чему это привело в partition.

FR>Что имеешь в виду под "мощнее" я не понял.

Выше был пример find — даже реализация базовых возможностей не была продемонстрирована на D, не говоря уж об [prev(find(first, last)), last)