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

DE>А почему работает и с круглыми скобками?

И так и так корректно. ) Просто создатели же специально делали чтобы в таких случаях можно было без скобок — надо уважать их усилия. )))

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

EP>>Как ты проверишь что индекс принадлежит правильному диапазону? В случае итераторов ещё можно включать проверки в debug — а с индексами что делать?
_>Вообще то проверка границ у массивов в D встроенная.

А что, например, делать с пользовательскими диапазонами?

_>Правда по умолчанию она выключена (@system). Но легко включается или флагами компилятора на весь проект или спец.атрибутом (@trusted или @safe) прямо в коде.

В реализациях STL она тоже встроена, и также есть ручки для включения/выключения. Если полагаться на эти проверки — то вообще не вижу смысла в обсуждении "опасности" итераторов.

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

J>Не, ну это неинтересно, я надеялся код на диапазонах увидеть, а массив и индексы...

Так я про это Евгению и пишу))) Нафиг не сдались мне эти диапазоны в D. )))

J>Ну что-нть вроде такого (пишу в браузере)
J>

J>template<class It, class Val>
J>It f25(It begin, It end, Val val)
J>{
J>  auto found = find( begin, end, val );
J>  auto even2 = prev(make_filter_iterator( is_even, found       ), 2);
J>  auto odd5  = next(make_filter_iterator( is_odd, even2.base() ), 4);
J>  return odd5.base();
J>}
J>

J>код будет работать с любыми двунаправленными итераторами — хоть массив, хоть двусвязный список...
J>Можно и честно через обратный итератор, если смущает "-2":

Угу, симпатично и так функциональненько. Хотя по длине так же как и мой вариант в лоб. ))) Ну если убрать объявление функции конечно же.

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

DM>По умолчанию включена. Выключается ключиком -noboundscheck. Но речь выше не только про массивы шла.

Нуу у меня -release стоит, так что у меня по умолчанию выключена. )))

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

DM>>Ты уже несколько раз этот код цитировал. И пытался из результата своего find строить "первую часть" диапазона для однопроходного итератора.
EP>Я не пытался, это бессмысленно. Для однопроходного я пытался получить вторую часть — а у тебя там был .save(), который есть только у forward.

Так ты же изначально просил функцию, возвращающую _обе_ части. Я ее и показал. Для однопроходного она смысла не имеет, поэтому использование .save абсолютно оправдано. Если нужна только вторая часть, есть уже готовые варианты find в библиотеке, и довольно короткие.

EP>В полном варианте find для range будет реализация takeExactly и костылей для RandomAccess и isSomeString — в итоге займёт строк сто, а в моём варианте их 7. Разве не очевидно что более подвержено ошибкам?

Твой вариант тоже не содержит всего кода для решения изначальной задачи (получения двух частей).

DM>>Опять повторяемся. Еще раз спрошу: как обращение по произвольному индексу в случае итераторов может быть безопаснее, чем в случае ренджей?
EP>Я уже показывал примеры — как минимум в случае итераторов будет меньше переменных, и это безопаснее.

Не будет. Там, где в плюсах инкремент итератора, в D popFront. Там где в плюсах обращение по индексу, в D обращение по индексу.

DM>>И какую конкретно проблему ты имел в виду по той ссылке?
EP>Использование и простых индексов и range'ей.

И почему это проблема?

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

EP>>В полном варианте find для range будет реализация takeExactly и костылей для RandomAccess и isSomeString — в итоге займёт строк сто, а в моём варианте их 7. Разве не очевидно что более подвержено ошибкам?
DM>Твой вариант тоже не содержит всего кода для решения изначальной задачи (получения двух частей).

Если не устраивает комбинация на пользовательской стороне, то пусть будет пара range'ей — максимум станет больше на одну строчку

DM>>>Опять повторяемся. Еще раз спрошу: как обращение по произвольному индексу в случае итераторов может быть безопаснее, чем в случае ренджей?
EP>>Я уже показывал примеры — как минимум в случае итераторов будет меньше переменных, и это безопаснее.
DM>Не будет. Там, где в плюсах инкремент итератора, в D popFront. Там где в плюсах обращение по индексу, в D обращение по индексу.

Если бы RandomAccessRange продолжил бы изначальную линию срезания концов диапазона — и оставил бы только popFrontN/popBackN, без обычного доступа по индексу — то так бы и было, но это ещё бы снизило их применимость, тут-то хоть одумались.
А с индексами получается:

// 5 entities:
w += n;
z += n/2;
x[w] = y[z];
// versus 3 entities:
x += n;
y += n/2;
*x = *y;

Семантика кода одинаковая, но переменных в случае итераторов — меньше

DM>>>И какую конкретно проблему ты имел в виду по той ссылке?
EP>>Использование и простых индексов и range'ей.
DM>И почему это проблема?

Большинство проблем присущих итераторам — например, нелегальное смешивание индексов из разных диапазонов, выход за границы.
Плюс дополнительные проблемы, которых нет у итераторов — "разыменовывавшие" индекса на неправильном диапазоне, что нельзя сделать на итераторах, by-design.

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

EP>// versus 3 entities:
EP>x += n;
EP>y += n/2;
EP>*x = *y;
EP>[/ccode] Семантика кода одинаковая, но переменных в случае итераторов — меньше

А кто мешает сделать

x.popFrontN(n);
y.popFrontN(n/2);
x[0] = y[0];

? Ровно те же сущности и операции.

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

DM>А кто мешает сделать
DM>

DM>x.popFrontN(n);
DM>y.popFrontN(n/2);
DM>x[0] = y[0]; 
DM>

DM>? Ровно те же сущности и операции.

Если ты так сделаешь — то опять вылезают проблемы с ростом "назад" и склейкой.
Или например помнишь лишние передёргивания в partition? Так вот, в partition который используется в quickSortImpl — этих передёргиваний нет, потому что индексы используются в качестве итераторов.
Если бы были те popFrontN которые ты показываешь — то передёргивания опять бы появились, и было бы ещё неудобней. Если думаешь что это не так — просто попробуй использовать popFrontN/popBackN в этом кусочке

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

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

IMHO, тут намного хуже то, что, насколько я понимаю, они не просто выдают новый интервал, но ещё и интервал ДРУГОГО ТИПА, так что комбинировать их без RTTI вообще нельзя. А это уже принципиальный прокол в производительности...

Или таки можно?

Вот смотри, пусть у меня есть односвязанный списко букв в виде интервала, и я хочу написать функцию, которая возвращает подпоследовательность этой последовательности от начала до символа '\n', либо до конца последовательности, если '\n', либо первые 100 символов, если последовательность длиннее, и в первых 100 нет '\n'.

Как такое написать эффективно?

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

VD>Ага. Это "пока" наблюдается самую малость — на протяжении 30 лет.
Ну за 30 лет в С++ многео поменялось. Но миксинов всё равно нет. зато есть POD'ы, кстати.

VD>"Например" не катит. Давай или признаем, что в области метапрограммирования С++ существенно уступает D, или вы продемонстрируете аналог генерации функции GetHashCode и мы сравним код.

Ну ты сам, что ли, не знаешь, как оно в С++ будет?
Будет что-то вроде:

class MyClass {
   Type1 F1;
   Type3 someImplementationDetail;
public:
   Type2 F2;

   operator CHasCalculator() const { return CHasCalculator::Seed << F1 << F2; }
};

Хуже то, что участвующие поля прийдётся указатьявно, лучше то, что можно выбрать какие из полей участвуют в хэше...

VD>Они банально удобно для функционального программирования, которое в D, так же поддерживается значительно лучше чем в С++ (без костылей в библиотеках).

Ну кто тебе мешает так же работать на итераторах-то? Они же все с семантикой значения.
ну напиши себе template<typename TIterator> TIterator succ( const TIterator& ); и template<typename TIterator> TIterator pred( const TIterator& ); и радуйся

Лучше поясни что делать с тем, что дишные диапазоны всё время приходится делать разного типа?

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

FR>compile-time reflection да хорошо, но мало, без миксинов и static if тоже будет сложно, близко по
FR>выразительности не повторить.

Вместо миксинов можно CRTP заюзать, например...
Будет чуть хуже, но не принципиально.

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

I>Я на самом деле на D смотрю с большой надеждой. Если он выстрелит нормально в фейсбуке, это будет очень большое событие

Смотря в куда выстрелит... А то из С++ выстрелить в ногу/голову/спину/грудь тоже неплохо можно

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

VD>Библиотеки дело наживное. Если бы люди вроде тебя вместо того чтобы искать фатальные достатки просто попробовали что-нить написать на Ди, то и библиотеки появились бы.

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

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

E>IMHO, тут намного хуже то, что, насколько я понимаю, они не просто выдают новый интервал, но ещё и интервал ДРУГОГО ТИПА, так что комбинировать их без RTTI вообще нельзя. А это уже принципиальный прокол в производительности...
E>Или таки можно?
E>Вот смотри, пусть у меня есть односвязанный списко букв в виде интервала, и я хочу написать функцию, которая возвращает подпоследовательность этой последовательности от начала до символа '\n', либо до конца последовательности, если '\n', либо первые 100 символов, если последовательность длиннее, и в первых 100 нет '\n'.
E>Как такое написать эффективно?

В начале топика как раз произошёл такой прокол

Автор: D. Mon
Дата: 23.10.13

— там два return'а, которые возвращают разные типы (ниже по ветке разбор). Пока был массив — там видимо работала специализация, но для общего случае оно не заведётся

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

VD>Кого это трогает? Комитет по С++ существует не менее 20 лет. За это время гора родила мышь.
О да! С++ комитет -- это что-то с чем-то.

но мы можем посмотреть на то, каких успехов смогли добиться те, кто развивают какой-нибудь иной язык без боьших вливаний в продвижение, ну там на Ди, Хаскель, Эн2, наконец...
Ланцетник-то хотя бы родил кто-нибудь из этих людей?
В реале все мы знаем и любим плюсы, пэхэрэ, ну там пёрл, прости Господи, с питоном... Это из тех, кого мегабаксами не толкали в каждый дом.

Так что, чисто по опыту языки, которые "пробились сами" делятся на две группы
1) Очень плохие.
2) Мало кому нужные.

Плюсы -- они из первой группы, а Ди -- из второй
Главный недостаток Ди лежит не в том, что там диапазоны или ещё что-то не то, а в том, что его в продакшин пускать страшно, так как стабильных версий нет, программистов нет, библиотек нет и всё такое.

И самая адекватная реклама ди приключится, когда Александерску из фейсбука уйдёт, а ди нет...
Тошльк ты веришь, что так и будет?

А то пока что всё выглядет так, что Ди, конечно хороший язык, но что бы ставить его в продакшин надо иметь в штате человека уровня Александреску...

VD>А в какой области то у него что-то лучше?
В области числа инсталляций написанного на нём кода, в области числа LOC на нём эксплуатируемых в продакшине, в области числа программистов, которые умеют и знают и т. д... Ты и сам всё знаешь.

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

VD>А они есть. Скорость копиляции, лучший интелисенс, качественное метапрограммирование, более высокоуровневый код. Это довольно много.


Ну, вот, например, надо нам писать драйвера какие-то, или числодробилки. На сколько все эти твои "довольно много" снизят стоимость разработки/поддержки?..

А теперь, положим нам надо какое-то формошлёпство с вебом пополам, насколько там Ди окажется ВЫГОДНЕЕ чем шарп?

Да, "выгоднее" это в баксах, а не в абстрактных понятиях, вроде "высокоуровневый код"...
Ы?

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

VD>У новых языков (D, Scala, F#, Nemerle, Kotlin, Haskel, ...) есть только одна проблема — размеры комьюнити. Куча народа, вроде вас, ходит и что-то там себе доказывает вместо того чтобы взять и начать помогать развивать перспективные языки.

Не, Влад, тебе, как фанату, задают прямой вопрос, "а зачем их развивать/осваивать, например, конеретно мне?"
А ты в ответ банановыми шкуракми кидаешься, программисты видите ли не те языки развивают...
А вообще-то все люди что-то своё делают, намного более востребованное и полезное, чем развивать какие-то н понятно кому и зачем нужные "новые языки"...

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

E>IMHO, тут намного хуже то, что, насколько я понимаю, они не просто выдают новый интервал, но ещё и интервал ДРУГОГО ТИПА, так что комбинировать их без RTTI вообще нельзя. А это уже принципиальный прокол в производительности...

RTTI там не используется как раз. Типы выводятся и определяются статически.

E>Вот смотри, пусть у меня есть односвязанный списко букв в виде интервала, и я хочу написать функцию, которая возвращает подпоследовательность этой последовательности от начала до символа '\n', либо до конца последовательности, если '\n', либо первые 100 символов, если последовательность длиннее, и в первых 100 нет '\n'.

E>Как такое написать эффективно?

auto firstLineOr100(R)(R xs)
{
    return xs.take(100).until('\n');
}

Всего и делов.
take тут берет до 100 элементов и делает это лениво, поэтому если встретится '\n', то дальше итерация не пойдет.

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

E>Главный недостаток Ди лежит не в том, что там диапазоны или ещё что-то не то, а в том, что его в продакшин пускать страшно, так как стабильных версий нет, программистов нет, библиотек нет и всё такое.

Этот замкнутый круг для всех малоизвестных языков актуален.

E>И самая адекватная реклама ди приключится, когда Александерску из фейсбука уйдёт, а ди нет...
E>Тошльк ты веришь, что так и будет?

В фейсбуке точно есть и другие люди, заинтересованные в D, еще в мае на конференции человек оттуда спрашивал Ал-ку когда же наконец им можно будет официально его использовать. Кстати, у него был довольно интересный доклад там.

E>А то пока что всё выглядет так, что Ди, конечно хороший язык, но что бы ставить его в продакшин надо иметь в штате человека уровня Александреску...

На той же майской DConf были люди из компании с сотней программистов (и без Ал-ку), где вообще весь код на D. Еще Remedy Games тоже его используют, так что прецеденты уже имеются.

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

E>IMHO, тут намного хуже то, что, насколько я понимаю, они не просто выдают новый интервал, но ещё и интервал ДРУГОГО ТИПА, так что комбинировать их без RTTI вообще нельзя. А это уже принципиальный прокол в производительности...

E>Или таки можно?

А в чём проблема? Это же и в C++ без проблем работает, а уж в D то и подавно. )

E>Вот смотри, пусть у меня есть односвязанный списко букв в виде интервала, и я хочу написать функцию, которая возвращает подпоследовательность этой последовательности от начала до символа '\n', либо до конца последовательности, если '\n', либо первые 100 символов, если последовательность длиннее, и в первых 100 нет '\n'.

E>Как такое написать эффективно?

auto l=SList!dchar(['а', 'б', 'в', 'г', 'д', 'е', 'ё'])[];
l.until('г').take(6).writeln();//выводит "абв"
l.until('Г').take(6).writeln();//выводит "абвгде"