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

J>Ну да, только он же и сам в конце презентации при обсуждении говорит, что
Как раз курсы английского вынуждено прогуливаю
J>Так что он и сам все прекрасно понимает.
В этом я не сомневаюсь. Хотелось бы понимать столько же

J>Не знаю, воспринимать ли его тезис как "и все остальное, не только СТЛ, можно тоже на них же сделать и забить на итераторы окончательно". Если это действительно то, что он хотел сказать, то это экстремизм. Если нет — то я не спорю тогда.
Не думаю. По крайней мере, та идея, что мне понравилась, касается исключительно STL.

J>Ну да. То, что он называет диапазонами, во многих других местах называется view.
J>Вот, например:
J>http://www.boost.org/libs/mpl/doc/refmanual/views.html
J>http://www.boost.org/libs/fusion/doc/html/fusion/view.html
Спасибо за ссылки, почитаю.
J>И я думаю, каждый уже успел написать свой собственный filtered_view и substring.
Если я правильно понимаю концепцию по названию, то это очень ходовые вещи, да.

J>ну, это он на слайдах промолчал, а на видео ему кучу вопросов поназадавали на эту тему, и он практически со всем согласился.
Блин. Пойду смотреть. Может, минут через 10 записи станет по-лучше со звуком.

J>С чего ему быть нехилым? Как раз наоборот (не компилировал, пишу в браузере):
Мдя, в экран помещается. Промахнулся.

J>http://www.boost.org/libs/iterator/doc/new-iter-concepts.html
Посмотрю, спасибо.

J>Вот, например, Boost.RangeEx (еще не в официальной поставке):
J>http://lists.boost.org/Archives/boost/2009/02/148682.php
J>можно будет писать нечто вроде
J>

J>container | boost::adaptors::filtered(_1==0) | | boost::adaptors::reversed
J>

А вот это я почитаю когда высплюсь

E>Давай будем взаимовежливы? Либо снизь тон, и общайся, так, что с тобой будет приятно болтать о преимуществах диапазонов, либо я не буду с тобой вести беседу...

Предлагаю прекратить болтать.

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

DS>Предлагаю прекратить болтать.

Вот у меня есть динамически определяемое число последовательностей. Ну, например std::vector<std::vector<double> >.
И как мне при помощи диапазонов отсортировать эту таблицу по третьей колонке, например?..

J>С прямым итератором это действительно так.
J>А вот у двунаправленного итератора будет еще и MovePrev — ы? Аналогично для итератора с произвольным доступом.

J>Концепция "диапазоны можут только уменьшаться" выглядит довольно сильно ограничивающей, когда мы переходим к итерациям.

Кстати, да. Мне ничего не мешает написать

template <class BaseIterator>
class TwoWayIteratorOnRange
{
public:

    typedef typename BaseIterator::Item Item;

    TwoWayIteratorOnRange(BaseIterator current, Range<BaseIterator> range)
    {
        this->current = current;
        this->range = range;
    }

    bool IsValid() const
    {
        return current.IsValid() and range.Contains(current);
    }     

    void MovePrevious() 
    {
        current.MovePrevious();
    }

    void MoveNext() 
    {
        current.MoveNext();
    }

    Item& GetCurrent() 
    {
        return current.GetCurrent();
    }  

private:

    BaseIterator current;
    Range<BaseIterator> range;
};

(Или что-то в таком духе.)

Вот вам диапазоны, используйте на здоровье. Но зачем же итераторы выбрасывать?

Вообще, ход мыслей Александреску, как мне кажется, совершенно прозрачен: в STL мы постоянно видим пары итераторов: begin-end, begin-end, begin-end… почему бы не объединить их в одну структуру?

Здравствуйте, Аноним, Вы писали:

А>Вообще, ход мыслей Александреску, как мне кажется, совершенно прозрачен: в STL мы постоянно видим пары итераторов: begin-end, begin-end, begin-end… почему бы не объединить их в одну структуру?

Ну дык boost::range...

Но почему при этом: "Iterators Must Go"?

Здравствуйте, Аноним, Вы писали:

А>Вот вам диапазоны, используйте на здоровье. Но зачем же итераторы выбрасывать?

boost::iterator_range. Желающие вполне могут обернуть вызовы STL, и наслаждаться. Но это как бы немного не то, что предложил Александреску.

А>Вообще, ход мыслей Александреску, как мне кажется, совершенно прозрачен: в STL мы постоянно видим пары итераторов: begin-end, begin-end, begin-end… почему бы не объединить их в одну структуру?

Нет. Посмотрите на интерфейс range, описанный в презентации.
Ну и личное мнение: если ход мыслей Александреску кажется прозрачным при первом прочтении, значит я чего-то не понял.

А>>Вот вам диапазоны, используйте на здоровье. Но зачем же итераторы выбрасывать?

DS>boost::iterator_range. Желающие вполне могут обернуть вызовы STL, и наслаждаться. Но это как бы немного не то, что предложил Александреску.

А то, что у меня в примере — это немного не то, что предложил Александреску, и немного не то, что в Boost.Range.

А>>Вообще, ход мыслей Александреску, как мне кажется, совершенно прозрачен: в STL мы постоянно видим пары итераторов: begin-end, begin-end, begin-end… почему бы не объединить их в одну структуру?

DS>Нет. Посмотрите на интерфейс range, описанный в презентации.

Цитата из презентации:

A range is a pair of begin/end iterators packed together

Здравствуйте, Аноним, Вы писали:

А>А то, что у меня в примере — это немного не то, что предложил Александреску, и немного не то, что в Boost.Range.

Да. И мне, как пользователю iterator_range, еще один range с доп расходами на хранение текущего состояния не нужен.

DS>>Нет. Посмотрите на интерфейс range, описанный в презентации.

А>Цитата из презентации:

А>

А>A range is a pair of begin/end iterators packed together

Цитата из меня: Посмотрите на интерфейс. Я не понимаю: вы хотите что-то обсудить или что-то доказать?