BoostCon - Alexandrescu - Iterators Must Go (video)
От: jazzer Россия Skype: enerjazzer
Дата: 03.08.09 23:47
Оценка: 5 (1)
http://boostcon.blip.tv/
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
boost iterator range andrei alexandrescu video talk keynote boostcon 2009
Re: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Rakafon Украина http://rakafon.blogspot.com/
Дата: 04.08.09 07:55
Оценка: -1
Здравствуйте, jazzer, Вы писали:
J>http://boostcon.blip.tv/

... я так понял Андрей "поносит" STL ... ?
... или это такой тонкий способ пропиарить язык программирования D ... ?
"Дайте мне возможность выпускать и контролировать деньги в государстве и – мне нет дела до того, кто пишет его законы." (c) Мейер Ансельм Ротшильд , банкир.
алеусандреску
Re[2]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: jazzer Россия Skype: enerjazzer
Дата: 04.08.09 16:10
Оценка:
Здравствуйте, Rakafon, Вы писали:

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

J>>http://boostcon.blip.tv/

R>... я так понял Андрей "поносит" STL ... ?

R>... или это такой тонкий способ пропиарить язык программирования D ... ?

и то, и другое

На самом деле, СТЛ сформулирован в основном в виде последовательностей.
Но при этом первоклассными сущностями, с которыми работают алгоритмы, являются итераторы.
Логично попробовать сделать сами последовательности первоклассными сущностями.

Библиотеки, которые эти занимаются, есть — это Adobe ASL.Algorithm (фактически СТЛ, реализованная в терминах последовательностей), Boost.Range/BangeEx (адаптеры и операции с последовательностями). Но они внутри все равно работают в терминах итераторов.

Андрей предлагает вообще от итераторов отказаться и делать все на последовательностях.
Идея хорошая, но спорная (по последовательностям же потом ходить надо, как ты их ни приготовь).

В бусте сейчас идет горячее обсуждение, я кидал линк в "Философии программирования".
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[3]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Аноним  
Дата: 04.08.09 19:02
Оценка:
Пардон, не последовательностей, а диапазонов (что и логически, и физически эквивалентно паре итераторов).

Идея остроумная, и она, безусловно, будет работать и неплохо, но при этом все равно дурацкая и добавит еще кривости и неинтуитивности STL.

Логически, диапазон — это все равно пара итераторов (указателей, ссылок на элементы). И попытка сказать, что итераторы якобы куда-то «ушли», будет бессмысленной: все равно, мысленно оперируя диапазонами, мы будем подразумевать итераторы.

Этого просто не может не быть. Потому что даже само определение диапазона обозначает пару указателей на элементы в каком-либо виде (я не говорю обязательно про итераторы, это не важно, это может быть любая сущность, идентифицирующая элемент упорядоченного множества).

И мистер Александреску тоже, оперируя диапазонами, будет оперировать итераторами, просто он будет делать вид, что никаких итераторов нет.

Это такой же прикол, как в C# указатели, замаскированные ссылочными типами: оперируя, фактически, указателями на объекты, мы делаем вид, что никаких указателей нет.
Re[3]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: c-smile Канада http://terrainformatica.com
Дата: 04.08.09 19:39
Оценка:
Здравствуйте, jazzer, Вы писали:

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


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

J>>>http://boostcon.blip.tv/

R>>... я так понял Андрей "поносит" STL ... ?

R>>... или это такой тонкий способ пропиарить язык программирования D ... ?

А D тут причем интересно...

J>и то, и другое


J>На самом деле, СТЛ сформулирован в основном в виде последовательностей.

J>Но при этом первоклассными сущностями, с которыми работают алгоритмы, являются итераторы.
J>Логично попробовать сделать сами последовательности первоклассными сущностями.

J>Библиотеки, которые эти занимаются, есть — это Adobe ASL.Algorithm (фактически СТЛ, реализованная в терминах последовательностей), Boost.Range/BangeEx (адаптеры и операции с последовательностями). Но они внутри все равно работают в терминах итераторов.


J>Андрей предлагает вообще от итераторов отказаться и делать все на последовательностях.

J>Идея хорошая, но спорная (по последовательностям же потом ходить надо, как ты их ни приготовь).

Для хождения используется range::popFront() и range::front(). Что заведомо надежнее чем it++ в который идеологически не заложена проверка на проход за end(). у range можно всегда спросить range::empty() он или нет.

На самом деле я давно гоняю эти ranges у себя ( tool::slice не совсем range но близко ) и могу сказать что действительно можно обойтись сугубо ими, т.е. без итераторов вообще. Кстати и stl я не использую в быту по причинам озвученным тёзкой, но это так — к слову.
Re[4]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Erop Россия  
Дата: 04.08.09 20:00
Оценка:
Здравствуйте, c-smile, Вы писали:

stl я не использую в быту по причинам озвученным тёзкой, но это так — к слову.

А что возвращают вские find'ы? диапазон из одного элемента (это если нашёл)?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 04.08.09 20:31
Оценка: 2 (1)
Здравствуйте, jazzer, Вы писали:

J>http://boostcon.blip.tv/


http://lambda-the-ultimate.org/node/3520
Там же лежит ссылка на keynote. ( http://www.boostcon.com/site-media/var/sphene/sphwiki/attachment/2009/05/08/iterators-must-go.pdf ).

ЗЫ. С моим английским такое качество аудио невоспринимаемо
Re[4]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 04.08.09 21:26
Оценка: :)
Здравствуйте, Аноним, Вы писали:

А>Пардон, не последовательностей, а диапазонов (что и логически, и физически эквивалентно паре итераторов).

А итератор и логически и, иногда, физически эквивалентен указателю. Положите молоток на место.

А>Идея остроумная, и она, безусловно, будет работать и неплохо, но при этом все равно дурацкая и добавит еще кривости и неинтуитивности STL.

Имхо вы "имхо" забыли добавить.

А>Логически, диапазон — это все равно пара итераторов (указателей, ссылок на элементы). И попытка сказать, что итераторы якобы куда-то «ушли», будет бессмысленной: все равно, мысленно оперируя диапазонами, мы будем подразумевать итераторы.

А работая с функциональным языком будем думать о реализации односвязного списка на C.

А>Этого просто не может не быть. Потому что даже само определение диапазона обозначает пару указателей на элементы в каком-либо виде (я не говорю обязательно про итераторы, это не важно, это может быть любая сущность, идентифицирующая элемент упорядоченного множества).т

Определение диапазона обозначает диапазон. Вводится новая концепция. Она пытается сделать ненужной концепцию итератора. Какое дело до реализации?

А>И мистер Александреску тоже, оперируя диапазонами, будет оперировать итераторами, просто он будет делать вид, что никаких итераторов нет.

А оперируя bind можно сделать вид, что функтора нет. Но мы то знаем, да? Так что bind не нужен, дружно едим кактус^W^Wпишем функторы.

А>Это такой же прикол, как в C# указатели, замаскированные ссылочными типами: оперируя, фактически, указателями на объекты, мы делаем вид, что никаких указателей нет.

Логика в этом предложении, как и указатели в C#, есть. Но что-то с ней не то
Re[5]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 04.08.09 21:29
Оценка:
Здравствуйте, Erop, Вы писали:

E>А что возвращают вские find'ы? диапазон из одного элемента (это если нашёл)?


Там вроде как написано:

return the range starting with the found element (if any), empty if not found

Re[6]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Erop Россия  
Дата: 04.08.09 21:36
Оценка:
Здравствуйте, Dmi3S, Вы писали:

DS>

DS>return the range starting with the found element (if any), empty if not found


А почему именно "начинающийся", а не "заканчивающийся"? Как-то нелогично несколько...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[4]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Erop Россия  
Дата: 04.08.09 21:41
Оценка:
Здравствуйте, Аноним, Вы писали:

А>И мистер Александреску тоже, оперируя диапазонами, будет оперировать итераторами, просто он будет делать вид, что никаких итераторов нет.


Это необязательно. От коллекции очень зависит. Скажем диапазон в дереве может выглядеть как коллекция веток.
Опять же, обычно std::vector -- это три указателя: на начало буфера, на конец заполненной части буфера и на конец буфера. По идее можно воспринимать вектор как указатель на конец буфера (или максимальную ёмкость) и диапазон заполненных элементов.

По идее, пара итереаторов -- это естественное представление только для двусвязанного списка.

Намного интереснее вопрос, что делать, когда нам нужен не диапазон, а позиция элемента в последовательности. Как тогдя избежать оверхеда не совсем понятно...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: исчо вопросы
От: Erop Россия  
Дата: 04.08.09 21:45
Оценка:
Здравствуйте, Dmi3S, Вы писали:

E>>А что возвращают вские find'ы? диапазон из одного элемента (это если нашёл)?


DS>

DS>return the range starting with the found element (if any), empty if not found


Ещё один хитрый вопрос -- что делать, если мне нужна позиция элемента, а не диапазон.
Ну, например, если у меня есть список элементов, и коллекция курсоров в нём. Ну, типа я что-то редактирую в multiview редакторе и в каждом окне хочу иметь свой курсор?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 04.08.09 21:47
Оценка: 12 (1)
Здравствуйте, Erop, Вы писали:

E>А почему именно "начинающийся", а не "заканчивающийся"? Как-то нелогично несколько...

Может, потому что должен существовать input_range, м.б. из-за элегантности определения find:

template<class R, class T>
R find(R r, T value);

“Reduces the range r from left until its front isо
equal with value or r is exhausted.”

Может, потому что применив find к полученному range, можно найти следующее вхождение.
Я привел несколько вполне себе логичных причин, и не вижу ни одной нелогичной.
Re[8]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Erop Россия  
Дата: 04.08.09 21:54
Оценка:
Здравствуйте, Dmi3S, Вы писали:


DS>Я привел несколько вполне себе логичных причин, и не вижу ни одной нелогичной.

Нет, откусывание слева всего ненужного -- это совсем не тоже самое, что "некий диапазон, начинающийся с..."
А rfind, откусывает справа?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: исчо вопросы
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 04.08.09 22:23
Оценка:
Здравствуйте, Erop, Вы писали:

E>Ещё один хитрый вопрос -- что делать, если мне нужна позиция элемента, а не диапазон.

Range от текущего элемента до конца коллекции имхо.
E>Ну, например, если у меня есть список элементов, и коллекция курсоров в нём.
Нет никаких курсоров. Впрочем, у коллекции несуществующих курсоров можно вызвать find, получить range и запомнить его.
Хотя, я бы запоминал результат find от списка элементов.
E>Ну, типа я что-то редактирую в multiview редакторе и в каждом окне хочу иметь свой курсор?
Тогда кому нужна коллекция курсоров? Не проще ли у каждого view спросить его конктретный курсор^Wrange, front которого вернет ссылку на соответствующий элемент?
Re[9]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 04.08.09 22:26
Оценка:
Здравствуйте, Erop, Вы писали:

E>Нет, откусывание слева всего ненужного -- это совсем не тоже самое, что "некий диапазон, начинающийся с..."

Откусывание это вообще не диапазон.
E>А rfind, откусывает справа?
Нет никакого rfind. Почитайте уже ссылку, что ли.
Re[8]: исчо вопросы
От: Erop Россия  
Дата: 04.08.09 22:35
Оценка:
Здравствуйте, Dmi3S, Вы писали:

DS>Тогда кому нужна коллекция курсоров? Не проще ли у каждого view спросить его конктретный курсор^Wrange, front которого вернет ссылку на соответствующий элемент?


1) Ну как бы хранить лишние данные (диапазон, вместо итератора на нужный элемент) как-то жаба давит...
2) Если в качестве курсоров хранить диапазон от нужного до конца, валидность моих курсоров начнёт зависеть от того, что делают с концом коллекции. Разве это удобно?...

Я наверное не понятно описал, что имеется в виду.
Положим у меня есть коллекция сотрудников. Я завожу массив итераторов, каждый из которых указывает на своего сотрудника, и потом сортирую этот массив по степени того, насколько этот сотрудник подходит для данной работы. Ну и что-то потом там с этим отсортированным массивом делаю. Я верно понимаю, что в подходе с диапазонами этот массив будет в два раза больше?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[10]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Erop Россия  
Дата: 04.08.09 22:38
Оценка:
Здравствуйте, Dmi3S, Вы писали:

DS>Откусывание это вообще не диапазон.

Это не интересно, так как это придирки к словам, а не замечание по сути. Если ты не понял, что я имел в виду, то я могу пояснить...

E>>А rfind, откусывает справа?

DS>Нет никакого rfind. Почитайте уже ссылку, что ли.
Она у меня не открывается. Видимо там PDF?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: исчо вопросы
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 04.08.09 23:09
Оценка:
Здравствуйте, Erop, Вы писали:

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


DS>>Тогда кому нужна коллекция курсоров? Не проще ли у каждого view спросить его конктретный курсор^Wrange, front которого вернет ссылку на соответствующий элемент?


E>1) Ну как бы хранить лишние данные (диапазон, вместо итератора на нужный элемент) как-то жаба давит...

В концепции range понятие курсора вообще плохо вписывается. range представляют собой концепцию списка, доступ к которому возможен только с головы (и с хвоста, в случае BidirRange). Соответственно, я слегка промахнулся в предыдущем посте: лучше в качестве курсора использовать range из одного элемента.

E>2) Если в качестве курсоров хранить диапазон от нужного до конца, валидность моих курсоров начнёт зависеть от того, что делают с концом коллекции. Разве это удобно?...

Валидность большинства курсоров начнет очень зависить от, если с коллекцией начнут что-то делать. Например, в случае vector.

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

Если имеется ввиду оверхид на range из одного элемента, то я не знаю ответа. Можно вывести специальный тип для оптимизации использования памяти. Состять он будет из ссылки на один элемент. Позволяет сделать один popFront() и т.д. Но это как бы детали.
Re[11]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 04.08.09 23:28
Оценка:
Здравствуйте, Erop, Вы писали:

DS>>Откусывание это вообще не диапазон.

E>Это не интересно, так как это придирки к словам, а не замечание по сути. Если ты не понял, что я имел в виду, то я могу пояснить...
Это не придирки, кэп.
Когда я пытаюсь предположить, почему же решили использовать 1й вариант, и как-то обосновать свою т.зр, а в ответ получаю, что 1й вариант — это совсем не 2ой, то остается только покорно согласиться с таким утврждением.

E>>>А rfind, откусывает справа?

DS>>Нет никакого rfind. Почитайте уже ссылку, что ли.
E>Она у меня не открывается. Видимо там PDF?
Да, pdf.
Re[5]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: c-smile Канада http://terrainformatica.com
Дата: 04.08.09 23:36
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, c-smile, Вы писали:


E>stl я не использую в быту по причинам озвученным тёзкой, но это так — к слову.


E>А что возвращают вские find'ы? диапазон из одного элемента (это если нашёл)?


[сcode]
range r = find(range where, element what);
[/сcode]

Ну и соотв. r будет либо empty() либо r.front() == what

Т.е. полный скан выглядит так:
for(range r = ...; ! find(r,'A').empty() ; r.pop_front())
{
  do something with r.front();
}
Re[6]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 04.08.09 23:47
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Т.е. полный скан выглядит так:

CS>
CS>for(range r = ...; ! find(r,'A').empty() ; r.pop_front())
CS>{
CS>  do something with r.front();
CS>}
CS>


Не совсем так.

for( auto r= find( where, 'A' ); !r.empty(); r.popFront(), r= find( r, 'A' ) )
{
  do something with r.front();
}
Re[7]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: c-smile Канада http://terrainformatica.com
Дата: 05.08.09 00:27
Оценка:
Здравствуйте, Dmi3S, Вы писали:

DS>
DS>for( auto r= find( where, 'A' ); !r.empty(); r.popFront(), r= find( r, 'A' ) )
DS>{
DS>  do something with r.front();
DS>}
DS>


Тогда уж так

for(range r = ...; !(r = find(r,'A')).empty() ; r.pop_front())
{
  do something with r.front();
}


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

А в реалии вообще-то чаще используется chop() за для "нарубить последовательность делиметром".

find() он по идее да/нет должен возвращать или сам range приводиться к bool без лишнего гемороя (на предмет non_empty()).

Т.е. как-то так:
for(range r = ...; (r = find(r,'A')) ; r.pop_front() )
{
  do something with r.front();
}
Re[4]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: jazzer Россия Skype: enerjazzer
Дата: 05.08.09 00:32
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Для хождения используется range::popFront() и range::front(). Что заведомо надежнее чем it++ в который идеологически не заложена проверка на проход за end(). у range можно всегда спросить range::empty() он или нет.


это дает возможность только для реализации for_each, которым, как известно, все не исчерпывается, и который, вообще говоря, можно засунуть непосредственно в диапазон — оно будет прямее, чем через фронты (например, диапазон, пользуясь знаниями о своей структуре, может сделать все сверхэффективно, параллельно, и т.п.).

А вот как ты организуешь, скажем, работу с многомерными массивами, или (простейшая задача для итераторов, я ее приводил в буст-листе) когда тебе нужен диапазон вокруг найденного элемента, т.е. [found-5,found+5)?
Как ты сможешь это сделать удобно на диапазонах, я не представляю.

CS>На самом деле я давно гоняю эти ranges у себя ( tool::slice не совсем range но близко ) и могу сказать что действительно можно обойтись сугубо ими, т.е. без итераторов вообще. Кстати и stl я не использую в быту по причинам озвученным тёзкой, но это так — к слову.


Я думаю, что классы типа твоего slice есть в каждом проекте (и у нас тоже). Только вот они не обеспечивают всей требуемой функциональности. Например, каких накладных расходов потребует фильтрация (хочу диапазон только из заглавных латинских букв)? А обращенная последовательность (reverse)? А оба сразу?

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

С другой стороны, в том же буст-листе говорили, что слайды плохие и реальная презентация не вполне им соответствует, так что когда будет время — посмотрю видео, может, он меня войсом убедит
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[10]: исчо вопросы
От: jazzer Россия Skype: enerjazzer
Дата: 05.08.09 01:05
Оценка:
Здравствуйте, Dmi3S, Вы писали:

DS>В концепции range понятие курсора вообще плохо вписывается.


Вот-вот.
Напоминает ситуацию с SQL, когда все такое в теории красивое теоретико-множественное и самодостаточное, а в реальности без кондовых курсоров никуда.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[5]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Аноним  
Дата: 05.08.09 06:09
Оценка:
Вы ничего не поняли. Перечитайте еще несколько раз, пожалуйста, только вдумчиво.
Re[5]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Аноним  
Дата: 05.08.09 06:26
Оценка: 6 (1)
E>Это необязательно. От коллекции очень зависит. Скажем диапазон в дереве может выглядеть как коллекция веток.

Почему тогда оно называется «диапазоном»?

«Диапазон» есть связное подмножество линейно упорядоченного множества. Если в вашем дереве можно выделить диапазон, значит его узлы линейно упорядочены, а если так, то в данном контексте безразлично, что это — дерево или не дерево, в любом случае — это линейно упорядоченное множество элементов (узлов дерева).

Диапазон однозначно определяется минимальным и максимальным элементами этого диапазона в линейно упорядоченном надмножестве.

Что и требовалось доказать — пара итераторов.

E>Опять же, обычно std::vector -- это три указателя: на начало буфера, на конец заполненной части буфера и на конец буфера. По идее можно воспринимать вектор как указатель на конец буфера (или максимальную ёмкость) и диапазон заполненных элементов.


Это эквивалентное определение диапазона. Диапазон вообще можно определить, например, так:

1) указать минимальный и максимальный элементы надмножества;
2) указать минимальный элемент и мощность диапазона (количество элементов в нем);
3) указать максимальный элемент и мощность диапазона (количество элементов в нем).

Ну и еще, по идее, можно придумать сто мильонов способов, но все они будут эквивалентны между собой и эквивалентны паре итераторов.

Минимально необходимо всегда два параметра, то есть, например, опять же, пара указателей (итераторов, индексов, ссылок, строковых идентификаторов и тому подобное).

E>По идее, пара итереаторов -- это естественное представление только для двусвязанного списка.


E>Намного интереснее вопрос, что делать, когда нам нужен не диапазон, а позиция элемента в последовательности. Как тогдя избежать оверхеда не совсем понятно...


Так это всего лишь логическое следствие той проблемы, о которой я и говорю.
Re[5]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: minorlogic Украина  
Дата: 05.08.09 07:39
Оценка: +1
Здравствуйте, Dmi3S, Вы писали:

DS>Определение диапазона обозначает диапазон. Вводится новая концепция. Она пытается сделать ненужной концепцию итератора. Какое дело до реализации?


Реализация очень важна. И накладные расходы и удобство использования. Итераторы в этих критериях сложно обогнать
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[6]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 05.08.09 09:01
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Вы ничего не поняли. Перечитайте еще несколько раз, пожалуйста, только вдумчиво.

Думаю да, я ничего не понял. Давайте по частям.
A>Логически, диапазон — это все равно пара итераторов (указателей, ссылок на элементы).
Вот тут я споткнулся. Поясните мысль пожалуйста.
Re[6]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 05.08.09 09:42
Оценка:
Здравствуйте, minorlogic, Вы писали:

DS>>Определение диапазона обозначает диапазон. Вводится новая концепция. Она пытается сделать ненужной концепцию итератора. Какое дело до реализации?


M>Реализация очень важна. И накладные расходы и удобство использования. Итераторы в этих критериях сложно обогнать


Конкретная реализация, безусловно, важна. Но ее нет. Обсуждается концепция и ее потенциальный win/fail: удобство использования, применимость, и т.д. Поэтому хотелось бы обсуждать subj именно с этой точки зрения.
Re[5]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 05.08.09 10:19
Оценка:
Здравствуйте, jazzer, Вы писали:

J>А вот как ты организуешь, скажем, работу с многомерными массивами, или (простейшая задача для итераторов, я ее приводил в буст-листе) когда тебе нужен диапазон вокруг найденного элемента, т.е. [found-5,found+5)?

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

Ranges вводят семантику контейнеров. Поэтому имхо единственный способ получить расширенный диапазон — попросить контейнер создать его.
contaier_t c;
auto r= find(c, 'A');
auto exr= c.create_range_at( r, 5 ); //create range [r-5,r+5]

Как работать с многомерными массивами я пока не представляю..
Re[7]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: minorlogic Украина  
Дата: 05.08.09 10:36
Оценка:
Здравствуйте, Dmi3S, Вы писали:

DS>Конкретная реализация, безусловно, важна. Но ее нет. Обсуждается концепция и ее потенциальный win/fail: удобство использования, применимость, и т.д. Поэтому хотелось бы обсуждать subj именно с этой точки зрения.


С этой точки зрения вселенский всемогутер намного лучше. В некоторых ситуациях типа find или проверка isEmpty из документа несут накладные расходы.
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[6]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: jazzer Россия Skype: enerjazzer
Дата: 05.08.09 10:52
Оценка:
Здравствуйте, Dmi3S, Вы писали:

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


J>>А вот как ты организуешь, скажем, работу с многомерными массивами, или (простейшая задача для итераторов, я ее приводил в буст-листе) когда тебе нужен диапазон вокруг найденного элемента, т.е. [found-5,found+5)?

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

DS>Ranges вводят семантику контейнеров.

Семантика контейнеров была и до диапазонов и отлично с ними и с итераторами сосушествовала, посмотри на тот же Boost.Range.

DS>Поэтому имхо единственный способ получить расширенный диапазон — попросить контейнер создать его.

DS>
DS>contaier_t c;
DS>auto r= find(c, 'A');
DS>auto exr= c.create_range_at( r, 5 ); //create range [r-5,r+5]
DS>

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

К слову, мне не вспоминается каких-либо реализаций диапазонов (в любых языках), которые могли бы расти сами по себе.
Везде единственный способ роста — это конкатенация с другим диапазоном.
Т.е. код будет примерно такой:

concat( take(find(с, 'A'), 5), take_last(before(с, x), 5) );

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

В принципе, можно заюзать сплит:
auto r_pair = split(с, 'A');
concat( take(r_pair[0], 5), take_last(r_pair[0], 5) );

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

DS>Как работать с многомерными массивами я пока не представляю..

Вот о чем и речь.
Чисто писано в бумаге, да забыли про овраги.
А по ним — ходить.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[8]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 05.08.09 10:54
Оценка:
Здравствуйте, minorlogic, Вы писали:

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


DS>>Конкретная реализация, безусловно, важна. Но ее нет. Обсуждается концепция и ее потенциальный win/fail: удобство использования, применимость, и т.д. Поэтому хотелось бы обсуждать subj именно с этой точки зрения.


M>С этой точки зрения вселенский всемогутер намного лучше. В некоторых ситуациях типа find или проверка isEmpty из документа несут накладные расходы.


Океюшки. Пример Zip из D.

int[] a = [ 1, 2, 3 ];
string[] b = [ "a", "b", "c" ];
// prints 1:a 2:b 3:c
foreach (e; zip(a, b))
{
    write(e.at!(0), ':', e.at!(1), ' ');
}


Вот примерный круг вопросов, который меня интересует. И только после этого уже стОит посмотреть на потенциальные накладные расходы. shared_ptr тоже вносит накладные расходы. Однако, свою область применения, кажется, имеет (sorry за многозначность).

PS. Вселенский всемогутер обсуждать не готов: боюсь, не хватит квалификации
Re[7]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 05.08.09 11:22
Оценка:
Здравствуйте, jazzer, Вы писали:

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


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


DS>>Поэтому имхо единственный способ получить расширенный диапазон — попросить контейнер создать его.

DS>>
DS>>contaier_t c;
DS>>auto r= find(c, 'A');
DS>>auto exr= c.create_range_at( r, 5 ); //create range [r-5,r+5]
DS>>

J>Получается, что диапазон знает не только о себе, но и о том, что вокруг него (по сути, несет на борту итератор).
Почему? В моем примере только контейнер знает что вокруг диапазона. И только контейнер может корректно создать новый диапазон на основе существующего.

J>К слову, мне не вспоминается каких-либо реализаций диапазонов (в любых языках), которые могли бы расти сами по себе.

Да я тоже не знаю. Поэтому и написал, что только контейнер может создать новый диапазон. Существующий диапазон может только уменьшаться до полной аннигиляции.

J>Везде единственный способ роста — это конкатенация с другим диапазоном.

J>Т.е. код будет примерно такой:

J>
J>concat( take(find(с, 'A'), 5), take_last(before(с, x), 5) );
J>

J>before — это предложид Андрей в буст-листе, когда ему указали на это проблему, изначально ее не было.
J>take_last — не помню, есть такая у него, или нет, но что-то должно быть.
J>[/ccode]
Да, это значительно более разумный интерфейс (забиваем на порядок вычеслений). Но суть та же -- без помощи контейнера ( вызов before() ) не обойтись.

DS>>Как работать с многомерными массивами я пока не представляю..

J>Вот о чем и речь.
J>Чисто писано в бумаге, да забыли про овраги.
J>А по ним — ходить.

Вот в D предлагают такое:
int[][] x = new int[][2];
x[0] = [1, 2];
x[1] = [3, 4];
auto ror = transversal(x, 1);
assert(equals(ror, [ 2, 4 ][]));

где ror имеет тип struct Transversal(RangeOfRanges,TransverseOptions opt = TransverseOptions.assumeJagged). Я пока что плохо себе представляю не то что реализацию на C++, но даже варианты и ограничения использования такого подхода. Но какие-то наработки, видимо, уже существуют.
Re[6]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Erop Россия  
Дата: 05.08.09 11:33
Оценка:
Здравствуйте, Аноним, Вы писали:

E>>Это необязательно. От коллекции очень зависит. Скажем диапазон в дереве может выглядеть как коллекция веток.


А>Почему тогда оно называется «диапазоном»?


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

А>Так это всего лишь логическое следствие той проблемы, о которой я и говорю.


Да нет, не правда. Диапазон можно воспринимать, как другой способ построить систему. Но не понятно как в этой другой системе решаются некоторые вещи...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: jazzer Россия Skype: enerjazzer
Дата: 05.08.09 11:35
Оценка: +1
Здравствуйте, Dmi3S, Вы писали:

DS>Океюшки. Пример Zip из D.


DS>Можно ли то же самое элегантно сделать с итераторами?

Разумеется, можно:
http://www.boost.org/libs/iterator/doc/zip_iterator.html
Даже синтаксис тот же самый.

DS>Что принципиально нельзя сделать из того, что позволяли итераторы?

не поверишь — нельзя итерироваться

DS>Что нового привносит данная концепция?

Имхо — ничего, если принимать во внимание существование Boost.Range.

DS>Каковы взаимоотношения контейнера и Ranges в плане валидности Ranges при изменение контейнеров? Необходимо ли вводить observers или можно жить по старым соглашениям от итераторов?

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

Диапазоны же эту проблему прячут под красивым интерфейсом.
В смысле, что и вектор — это диапазон, и его подвектор — это тоже диапазон.
Только вот понятия о времени жизни и валидности у них совершенно разные — с первым ты можешь делать что хочешь, а вот второй в результате этих действий сломается.
А если разносить понятия и говорить, что контейнеры — отдельно, а диапазоны — отдельно, то я не вижу ничего принципиально нового по сравнению с парой итераторов, который в этот контейнер смотрят.

Единственная проблема, которую я вижу с итераторами, ее хорошо продемонстрировал Adriano в "Философии" — это то, что сейчас итераторы в текущей организации STL должны быть одного типа, хотя реально это почти никогда не нужно. Т.е. если ты делаешь фильтрующий итератор, то тебе нужен только тяжелый begin, а для end вполне достаточно легкого end из контейнера. Но вот типы у них тогда будут разными, а значит, ни один алгоритм их в себя не всосет, потому что алгоритмы записываются так:
template<class Iterator>
for_each(Iterator begin, Iterator end);

Если их переписать в виде
template<class BeginIterator, class EndIterator>
for_each(BeginIterator begin, EndIterator end);

то мы сможем засовывать туда любые итераторы, лишь бы они имели в основании один и тот же контейнер.
Можно было бы возразить, что мы тогда теряем контроль типов, потому что теперь можем пропустить алгоритм по любым двум несвязанным итераторам, но эта проблема существует и сейчас с одинаковыми типами итераторов, так что одинаковый тип тут дает мало выгоды.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[10]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 05.08.09 12:47
Оценка:
Здравствуйте, jazzer, Вы писали:

DS>>Что нового привносит данная концепция?

J>Имхо — ничего, если принимать во внимание существование Boost.Range.
Навскидку.

More composition opportunities
• Stride: span a range several steps at once
Iterators can’t implement it!

Re[10]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 05.08.09 12:52
Оценка:
Здравствуйте, jazzer, Вы писали:

DS>>Что нового привносит данная концепция?

J>Имхо — ничего, если принимать во внимание существование Boost.Range.
Забыл про "sentinel-terminated containers". Неплохой пример null-terminated strings.
Re[11]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: jazzer Россия Skype: enerjazzer
Дата: 05.08.09 13:13
Оценка:
Здравствуйте, Dmi3S, Вы писали:

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


DS>>>Что нового привносит данная концепция?

J>>Имхо — ничего, если принимать во внимание существование Boost.Range.
DS>Забыл про "sentinel-terminated containers". Неплохой пример null-terminated strings.

istream_iterator?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[11]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: jazzer Россия Skype: enerjazzer
Дата: 05.08.09 13:20
Оценка:
Здравствуйте, Dmi3S, Вы писали:

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


DS>>>Что нового привносит данная концепция?

J>>Имхо — ничего, если принимать во внимание существование Boost.Range.
DS>Навскидку.
DS>

DS>More composition opportunities
DS>• Stride: span a range several steps at once
DS>Iterators can’t implement it!

Stride — это когда advance(1) эквивалентен advance(n)?
И почему же итераторы этого не могут?

не, многие операции над последовательностями (т.е. превращения одних последовательностей в другие) делаются легче и прямее, когда они описаны в терминах последовательностей, тут никто не спорит (хотя тоже с оговорками — некоторые превращения могут включать в себя нетривиальное итерирование).
Но это же не повод свести к последовательностям вообще всё, начиная с итераторов.

Это все равно что сказать, что на классах круче и удобнее писать, поэтому давайте забаним фундаментальные типы (int, double...).

Всему свое место.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[12]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 05.08.09 13:33
Оценка:
Здравствуйте, jazzer, Вы писали:

DS>>Забыл про "sentinel-terminated containers". Неплохой пример null-terminated strings.


J>istream_iterator?


Руль где-то рядом

istream_iterator<...> b( str );
istream_iterator<...> b1= b;
++b;
*b1; // Oops
Re[12]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 05.08.09 13:37
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Stride — это когда advance(1) эквивалентен advance(n)?

J>И почему же итераторы этого не могут?

Я так понял, что фишка в том, что сделав advance(n) на random-access итератор можно выскочить за end(). Соответственно, безопасный способ это n*(advance(1)+if(!end)). А в range, вроде как, это можно сделать эффективнее.
Re[13]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 05.08.09 13:39
Оценка:
Здравствуйте, Dmi3S, Вы писали:

DS> ... random-access итератор ...


это вот я зря написал.
Re[12]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 05.08.09 14:08
Оценка:
Здравствуйте, jazzer, Вы писали:

J>не, многие операции над последовательностями (т.е. превращения одних последовательностей в другие) делаются легче и прямее, когда они описаны в терминах последовательностей, тут никто не спорит (хотя тоже с оговорками — некоторые превращения могут включать в себя нетривиальное итерирование).

J>Но это же не повод свести к последовательностям вообще всё, начиная с итераторов.

Я так понимаю, что выжить должен только один. Ни кто не пойдет на удвоение заголовков функций, которые будут работать как с ranges, так и с итераторами. Соответственно, в этом ключе Александреску и сделал свой доклад. То, что для большинства алгоритмов больше подходят последовательности, как бы очевидно. Но вот что при таком раскладе делать пользователям — не понятно совершенно. Не тяжело, конечно, прочитать 10-15 страниц по LISP, и сделать выводы. Тяжело сознательно идти на потери памяти/данных/читаемости ради красоты. Да еще и не иметь выбора. И что тут предложить, я не знаю. Опять же, в LISP список (т.е. то, на что range) считается неизменным. Невозможна ситуация, когда кто-то втихую сказал контейнеру clear(). В плюсах же...
Если интересует мое личное мнение, то пока что ranges не кажутся мне жизнеспособной альтернативой. Но тенденция радует, да

J>Это все равно что сказать, что на классах круче и удобнее писать, поэтому давайте забаним фундаментальные типы (int, double...).

И вывести эти классы из System.ValueType

PS. Некорректное сравнение, я знаю. Но удержаться не смог.
Re[13]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: jazzer Россия Skype: enerjazzer
Дата: 05.08.09 15:35
Оценка:
Здравствуйте, Dmi3S, Вы писали:

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


J>>Stride — это когда advance(1) эквивалентен advance(n)?

J>>И почему же итераторы этого не могут?

DS>Я так понял, что фишка в том, что сделав advance(n) на random-access итератор можно выскочить за end(). Соответственно, безопасный способ это n*(advance(1)+if(!end)). А в range, вроде как, это можно сделать эффективнее.


Для random-access-итератора это будет просто advance( min(n,distance(i,end)) ).
цикл, соответственно, будет не while(++i != end), а while(advance( min(n,distance(i,end)) ) != end) — имхо, не принципиальное усложнение.
end тут сидит в любом случае, потому что в любом случае тебе нужно условие окончания цикла.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[13]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: jazzer Россия Skype: enerjazzer
Дата: 05.08.09 15:45
Оценка:
Здравствуйте, Dmi3S, Вы писали:

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


J>>не, многие операции над последовательностями (т.е. превращения одних последовательностей в другие) делаются легче и прямее, когда они описаны в терминах последовательностей, тут никто не спорит (хотя тоже с оговорками — некоторые превращения могут включать в себя нетривиальное итерирование).

J>>Но это же не повод свести к последовательностям вообще всё, начиная с итераторов.

DS>Я так понимаю, что выжить должен только один. Ни кто не пойдет на удвоение заголовков функций, которые будут работать как с ranges, так и с итераторами. Соответственно, в этом ключе Александреску и сделал свой доклад.

Ну, я лично не вижу в этом радикальной проблемы.
Вон, Adobe с ASL фактически продублировали интерфейс СТЛ, и ничего, вроде, живут..
Хотя, по совести говоря, я голыми алгоритмами из STL и не пользуюсь практически, все время ASL, а зачастую и Boost.Foreach, когда нужно тупо пройтись по всему контейнеру/диапазону и что-то сделать, а функтор писать смысла нету (и такое бывает часто, естественно).

DS>То, что для большинства алгоритмов больше подходят последовательности, как бы очевидно. Но вот что при таком раскладе делать пользователям — не понятно совершенно. Не тяжело, конечно, прочитать 10-15 страниц по LISP, и сделать выводы. Тяжело сознательно идти на потери памяти/данных/читаемости ради красоты. Да еще и не иметь выбора. И что тут предложить, я не знаю.

Я вижу гибридный подход.
Диапазоны — диапазонами, и мы должны, безусловно, иметь полный набор операций над ними, но и итераторы никуда не денутся, чтобы ходить по тем же диапазонам.

DS>Опять же, в LISP список (т.е. то, на что range) считается неизменным. Невозможна ситуация, когда кто-то втихую сказал контейнеру clear(). В плюсах же...

Ну это уже из другой оперы вопрос, и он одинаково применим как к итераторам, так и к диапазонам.

DS>Если интересует мое личное мнение, то пока что ranges не кажутся мне жизнеспособной альтернативой. Но тенденция радует, да

Ну, мое имхо, что если не заниматься джихадом, то ranges отлично будут жить, потому что они фактически играют роль итераторов на стероидах.
Но я вот не поверю, что реализация какой-нть хитрой итерации на диапазонах порулит по скорости и памяти итерацию на голых итераторах, если не сказать — указателях.
В общем, диапазоны — вещь хорошая и удобная, и я уже давно ими пользуюсь в виде Adobe.ASL (которая внутри себя дергает просто Boost.Range) — код становится гораздо чище. Но в некоторых ситуациях от итераторов (ну или позиций в диапазоне, что, по сути, тоже является итератором) никуда, разве что ценой кривого и неудобного кода.

J>>Это все равно что сказать, что на классах круче и удобнее писать, поэтому давайте забаним фундаментальные типы (int, double...).

DS>И вывести эти классы из System.ValueType
Ага, именно на это я и намекал. Еще надо искоренить все свободные функции, тоже сделать их классами — и ведь даже языки такие есть.... Которые теперь изворачиваются через всякие костыли в виде анонимных классов...
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Аноним  
Дата: 05.08.09 16:35
Оценка:
Меня вообще все это удивляет, ей-богу.

Есть же куда более простое, интуитивное и эффективное решение (уже давно известное в других языках): чтобы итератор сам знал — валиден он или нет.

При таком подходе и диапазоны легко сделать: диапазон просто будет частным случаем итератора.

Но при этом итератор по односвязному списку, например, диапазоном не будет: это будет вообще один указатель, а у Александреску все равно придется делать два указателя, даже если это не нужно.

У Александреску если нужно указать один элемент, нужен будет вырожденный диапазон, а это будет не то, чтобы даже часто, а просто постоянно.

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

Это, кстати, нарушение знаменитого принципа "не платить за то, что не используешь".
Re[14]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 05.08.09 16:45
Оценка:
Здравствуйте, jazzer, Вы писали:

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


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


J>Для random-access-итератора это будет просто advance( min(n,distance(i,end)) ).

J>цикл, соответственно, будет не while(++i != end), а while(advance( min(n,distance(i,end)) ) != end) — имхо, не принципиальное усложнение.
J>end тут сидит в любом случае, потому что в любом случае тебе нужно условие окончания цикла.

Я начинаю понимать, что же я не понимал раньше
Скажем, есть алгоритм сортировки sort, работающий с range. Есть некий вектор. Задача состоит в том, чтобы расставить в порядке возрастания все элементы, стоящие на позициях кратных 13. Решение будет выглядеть примерно так:
vector vec;
// fill vec ...
sort( stride(vec,13) );

Конечно, тут можно вспомнить о boost::counting_iterator, и сказать, что эта функциональность, пусть и не в таком сахарном виде, уже есть. В ответ можно предположить, что нам потребовался еще и каждый 19й элемент:
vector vec;
// fill vec ...
sort( chain(stride(vec,13),stride(vec,19)) );

Конечно, пример искусственен. Но он мне нравится, и возможность использования range в таком стиле -- несомненный плюс имхо.
Re[2]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 05.08.09 17:33
Оценка:
Все очень понравилось.
Первое место:
А>При таком подходе и диапазоны легко сделать: диапазон просто будет частным случаем итератора.

Жду продолжения.
Re[3]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Аноним  
Дата: 05.08.09 19:02
Оценка:
DS>Жду продолжения.

template <class BaseIterator>
class ForwardRangeIterator
{
public:

    typedef typename BaseIterator::Item Item;

    ForwardRangeIterator(BaseIterator begin, BaseIterator end) 
    {
        this->current = begin;
        this->end = end;
    }

    bool IsValid() const
    {
        return current.IsValid() and current != end; 
    }     

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

    Item& GetCurrent() 
    {
        return *current;
    }  

private:

    BaseIterator current;
    BaseIterator end;
};
Re[4]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 05.08.09 19:05
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Крайне глупой мне представляется итерация по списку с помощью вырожденного диапазона, указывающего на один элемент.
Re[5]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Аноним  
Дата: 05.08.09 19:20
Оценка:
Крайне глупой мне представляется итерация по списку с помощью вырожденного диапазона, указывающего на один элемент [там, где для этого нет никакой необходимости].

(Это пояснение для тех, кто в танке, потому что из контекста это и так прекрасно должно быть понятно.)
Re[5]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Аноним  
Дата: 05.08.09 19:26
Оценка:
А>>Крайне глупой мне представляется итерация по списку с помощью вырожденного диапазона, указывающего на один элемент.

Да и потом, это к чему? У меня в примере кода нет никакого вырожденного диапазона.
Re[6]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 05.08.09 19:26
Оценка:
Здравствуйте, Аноним, Вы писали:

Рекомендация из танка: расскажите это Джону Маккарти. Так же, в принципе, можно подумать над нелепостью вызова sort( b, e ), где ++b == e.
Re[6]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 05.08.09 19:28
Оценка:
Здравствуйте, Аноним, Вы писали:

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


А>Да и потом, это к чему? У меня в примере кода нет никакого вырожденного диапазона.


Т.е. этим итератором даже по списку пройтись нельзя?
Re[7]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Аноним  
Дата: 05.08.09 19:35
Оценка: :)
DS>Т.е. этим итератором даже по списку пройтись нельзя?

Не понял, вы код читали? Он же элементарен.

Итератор хранит указатель на конец диапазона и, таким образом, позволяет выполнить алгоритм, производящий итерацию на диапазоне произвольного множества, у которого есть однонаправленный итератор.

Избыточность в этом случае равна нулю, то есть лишних данных нигде не хранится и не передается (если только не учитывать специфику конкретного контейнера).

Вырожденных диапазонов тоже нет («вырожденным» я в данном случае называю диапазон, который содержит лишь один элемент).
Re[8]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 05.08.09 20:29
Оценка:
Здравствуйте, Аноним, Вы писали:

DS>>Т.е. этим итератором даже по списку пройтись нельзя?


А>Не понял, вы код читали? Он же элементарен.

Да, читал.

А>Итератор хранит указатель на конец диапазона и, таким образом, позволяет выполнить алгоритм, производящий итерацию на диапазоне произвольного множества, у которого есть однонаправленный итератор.

Кэп, не узнал вас.

А>Избыточность в этом случае равна нулю, то есть лишних данных нигде не хранится и не передается (если только не учитывать специфику конкретного контейнера).


А>Вырожденных диапазонов тоже нет («вырожденным» я в данном случае называю диапазон, который содержит лишь один элемент).


Ок, вопросы для самопроверки.

Как мне воспользоваться этим итератором для того, чтобы указать на int [10]? // это к слову, но ведь иногда приходится.
Как этим итератором указать на один элемент?
Если мысленно выкинуть из кода непрозрачную IsValid(), typedef и сделать
s/ForwardRangeIterator/range
s/MoveNext/popFront
s/GetCurrent/front
, то полученный результат ни чего не напомнит?
Почему конструкция, семантически эквивалентная range, который инкапсулирует работу со списком итераторов, называется Bla_bla_bla_Iterator?
Что такое range?
Что такое итератор?
В чем разница между ними?
Почему использовать частный случай range "список указателей с одним элементом" противоестественно?
Почему использовать <неразборчиво> случай "iterator (указатель на один элемент) является списком" естественно?
Как обсуждать эти концепции с человеком, у которого граница между списком указателей и указателем на один элемент проходит не там же, где и у вас?
А если эта граница плавает в пределах одного предложения?

Доп. вопрос.
Как может быть реализована функция IsValid() в каком-либо из возможных BaseIterator? (ключевое слово observer)
Прим.
Ответ на доп вопрос IsValid() { return true; } уже получен от КО.
Re[9]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: jazzer Россия Skype: enerjazzer
Дата: 06.08.09 02:11
Оценка:
Здравствуйте, Dmi3S, Вы писали:

DS>s/MoveNext/popFront

DS>, то полученный результат ничего не напомнит?

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

Концепция "диапазоны можут только уменьшаться" выглядит довольно сильно ограничивающей, когда мы переходим к итерациям.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[8]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Аноним  
Дата: 06.08.09 07:21
Оценка: :))
Тов. "superman", к чему относится эта глупая улыбка? Вы разговаривать-то умеете? Если несогласны, попробуйте сказать-то хоть что-нибудь.
Re[10]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 06.08.09 17:35
Оценка:
Здравствуйте, jazzer, Вы писали:

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


DS>>s/MoveNext/popFront

DS>>, то полученный результат ничего не напомнит?

J>С прямым итератором это действительно так.

J>А вот у двунаправленного итератора будет еще и MovePrev — ы? Аналогично для итератора с произвольным доступом.
Я как бы хотел узнать, можно ли исходную конструкцию назвать итератором, и чем она отличается от range. В возможности добавления туда игр и девушек я не сомневался

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

Да, с использованием списков итерирование фактически невозможно. Это же начальные условия.

Я вообще как-то плохо понимаю: такое ощущение, что все старательно подходят с молотком к новому шурупу, и делают соответствующие выводы.

Неужели ни кому не нравится вот такая возможность:
vector<double> v1, v2;
deque<double> d;
partial_sort(v1, chain(v2, d));
sort(chain(v1, v2, d));

или вот такая:
vector<double> vd;
vector<string> vs;
deque<int>     vi;
// sort the three in lockstep
sort(zip(vs, vd, vi));


PS. Посмотрел на boost::zip_iterator. Сомневаюсь, что читаемый аналог второго примера влезет в экран.
Re[11]: Мама! А зачем все эти навороты в зоопарке? ;)
От: Erop Россия  
Дата: 06.08.09 18:08
Оценка:
Здравствуйте, Dmi3S, Вы писали:

DS>Неужели ни кому не нравится вот такая возможность:

DS>
DS>vector<double> v1, v2;
DS>deque<double> d;
DS>partial_sort(v1, chain(v2, d));
DS>sort(chain(v1, v2, d));
DS>

А зачем это всё нужно?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[12]: Мама! А зачем все эти навороты в зоопарке? ;)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 06.08.09 18:33
Оценка:
Здравствуйте, Erop, Вы писали:

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


DS>>Неужели ни кому не нравится вот такая возможность:

DS>>
DS>>vector<double> v1, v2;
DS>>deque<double> d;
DS>>partial_sort(v1, chain(v2, d));
DS>>sort(chain(v1, v2, d));
DS>>

E>А зачем это всё нужно?

В смысле?
Этот конкретный пример нужен для демонстрации лаконичности ranges.
Частично отсортировать элементы по трем контейнерам? эээ, ну, ммм... Ну собрали три лукошка с грибами. Нужно отобрать лукошко красивых, а остальные -- на посол. Или как-то так. Сходу нормальный пример не придумать, да. Впрочем, я и для boost::mpl годный пример вот так запросто не выдумаю.
range — нужен как альтернативный подход к склейке алгоритмов и контейнеров в STL.
Re[12]: Мама! А зачем все эти навороты в зоопарке? ;)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 06.08.09 18:52
Оценка:
Здравствуйте, Erop, Вы писали:

E>А зачем это всё нужно?


Александреску:

Range-based design offers much more than a port of iterator-based functions to ranges

Re[13]: Мама! А зачем все эти навороты в зоопарке? ;)
От: Erop Россия  
Дата: 06.08.09 19:02
Оценка:
Здравствуйте, Dmi3S, Вы писали:

DS>Частично отсортировать элементы по трем контейнерам? эээ, ну, ммм... Ну собрали три лукошка с грибами. Нужно отобрать лукошко красивых, а остальные -- на посол. Или как-то так. Сходу нормальный пример не придумать, да. Впрочем, я и для boost::mpl годный пример вот так запросто не выдумаю.

IMHO, если бы был конкретный пример было бы на много понятнее так ли это удобно, как тебе кажется...

Вот в том же примере с тремя корзинками с грибамИ, люди как-то обходятся без создания "обощённой корзинки".
Ещё неочевидна эффективность такого подхода, кстати...

DS>range — нужен как альтернативный подход к склейке алгоритмов и контейнеров в STL.


Не понятно зачем это всё-таки надо. IMHO, единственный вменяемый пример -- это параллельные массивы, что в свою очередь очень сомнительная практика

Опять же. А что будет, если я напишу что-то типа
sort(chain(v1, chain( v2, v1 )));
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[14]: Мама! А зачем все эти навороты в зоопарке? ;)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 06.08.09 19:42
Оценка:
Здравствуйте, Erop, Вы писали:

E>IMHO, если бы был конкретный пример было бы на много понятнее так ли это удобно, как тебе кажется...

Есть три очереди запросов. Нужно перебросить максимально возможное количество определенных запросов в первую очередь, а не соответствующие — перераспределить по оставшимся. Критерий отбора — использование ресурсов A,B,C. Веса по ресурсам: 0.7, 0.2, 0.1. Запросы могут сообщать об используемых ресурсах.
Да, и мне не кажется. Это мое мнение (мне нравится идея ranges), и я его аргументирую.

E>Вот в том же примере с тремя корзинками с грибамИ, люди как-то обходятся без создания "обощённой корзинки".

"Обобщенный стол" их выручает?
E>Ещё неочевидна эффективность такого подхода, кстати...
Т.е.? Есть способ эффективнее?

E>Не понятно зачем это всё-таки надо. IMHO, единственный вменяемый пример -- это параллельные массивы, что в свою очередь очень сомнительная практика

Динамическое создание структур данных в C++ пока даже не предвидется.

E>Опять же. А что будет, если я напишу что-то типа
sort(chain(v1, chain( v2, v1 )));

Делить на ноль не запретишь... Хотя у chain и достаточно данных, чтобы отловить такую последовательность, но принимать решение о некорректности может только функция sort: если это требуется, например, отправить на ostream, то все как раз именно так и должно быть. Впрочем, 0 тоже можно на ostream.
Re[15]: Мама! А зачем все эти навороты в зоопарке? ;)
От: Erop Россия  
Дата: 06.08.09 21:13
Оценка:
Здравствуйте, Dmi3S, Вы писали:

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


E>>IMHO, если бы был конкретный пример было бы на много понятнее так ли это удобно, как тебе кажется...

DS>Есть три очереди запросов. Нужно перебросить максимально возможное количество определенных запросов в первую очередь, а не соответствующие — перераспределить по оставшимся. Критерий отбора — использование ресурсов A,B,C. Веса по ресурсам: 0.7, 0.2, 0.1. Запросы могут сообщать об используемых ресурсах.

Не понял при чём тут ресурсы и веса. Типа есть три лиги, первая, вторая и третья. При этом число мест в каждой фиксировано. И надо типа перебросить самых лучших в первую лигу из второй и третьей? Такая задача?
Не понятно, зачем тут что-то с чем-то сливать, я не понимаю.
Например, было бы логично потребовать, чтобы те, кого переброска не затронула, сохранили бы свою лигу... На слитой последовательности, IMHO, сделать это не так-то и просто.
С другой стороны, если мы можем отсортировать каждую лигу, то решение тривиально: N-путевым слияением итерируем отсортированные три лиги и наводим порядок...

E>>Вот в том же примере с тремя корзинками с грибамИ, люди как-то обходятся без создания "обощённой корзинки".

DS>"Обобщенный стол" их выручает?

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

E>>Ещё неочевидна эффективность такого подхода, кстати...

DS>Т.е.? Есть способ эффективнее?
Ну я так понимаю, что все эти объединённые диапазоны при доступе к каждому элементу будут злобно очень ветвиться, в то время, как алгоритм
1) отсортировать все три корзины
2) итерировать лучшую с конца, а остальные с начала пока есть кандидаты на обмен...

DS>Динамическое создание структур данных в C++ пока даже не предвидется.

Не совсем понятно зачем нужны динамически созданные структуры. Код-то пишется ещё ДО КОМПИЛЯЦИИ?

DS>Делить на ноль не запретишь... Хотя у chain и достаточно данных, чтобы отловить такую последовательность, но принимать решение о некорректности может только функция sort: если это требуется, например, отправить на ostream, то все как раз именно так и должно быть. Впрочем, 0 тоже можно на ostream.


Ну это к тому, что легко граблей напрогать, а как проверить напрогали ли граблей -- не ясно
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: Мама! А зачем все эти навороты в зоопарке? ;)
От: Erop Россия  
Дата: 06.08.09 21:27
Оценка:
Здравствуйте, Dmi3S, Вы писали:

E>>А зачем это всё нужно?

DS>Александреску:
DS>

DS>Range-based design offers much more than a port of iterator-based functions to ranges


Ну типа ещё и пирожки печёт что ли?
Какие конкретно задачи будут лучше решаться-то? Есть какие-то неумозрительные примеры?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[16]: Мама! А зачем все эти навороты в зоопарке? ;)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 06.08.09 22:12
Оценка:
Здравствуйте, Erop, Вы писали:

E>Не понял при чём тут ресурсы и веса.

Критерий сотрировки как бы. Но это так, чтобы не скучно было. Концептуально — не при чем.

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

Да, лучших по определенному критерию.

E>Не понятно, зачем тут что-то с чем-то сливать, я не понимаю.

У нас всего 60 игроков. Надо в первую лигу запихнуть 20 лучших. В таком виде задача реализуется за один вызов partial_sort. Значит, нам осталось только собрать вместе 60 игроков, что мы и делаем, указывая в качестве второго range chain(liga2,liga3);
E>Например, было бы логично потребовать, чтобы те, кого переброска не затронула, сохранили бы свою лигу... На слитой последовательности, IMHO, сделать это не так-то и просто.
насколько я знаю, partial_sort не занимается лишними перестановками.
E>С другой стороны, если мы можем отсортировать каждую лигу, то решение тривиально: N-путевым слияением итерируем отсортированные три лиги и наводим порядок...
3 сортировки + 1 самописный алгоритм вместо вызова одной функции разбиения? Тогда давайте говорить за эффективность,
количество кода, скорость написания и отладки.

Вот примерный вариант c использованием ranges:

#include <...>
using namespace std;

void MoveBests( vector<player>& liga1, 
                deque<player>& liga2, 
                deque<player>& liga3,
                boost::finction< bool ( const player& , const player& ) > crit )
{ 
     partial_sort( liga1, chain( liga2, liga3 ), crit );
}


И, кстати, судя по частоте употребления слова "слияние", вы под ним что-то нехорошее подразумеваете. Что-то вроде копирования контейнеров. Этого нет. Под слиянеим понимается объединение двух ranges в один новый range.

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

По-подробнее пожалуйста. Потому как задачи (лиги,лукошки) эквивалентны, а ваши решения -- нет.
E>Ну я так понимаю, что все эти объединённые диапазоны при доступе к каждому элементу будут злобно очень ветвиться, в то время, как алгоритм
E>1) отсортировать все три корзины
E>2) итерировать лучшую с конца, а остальные с начала пока есть кандидаты на обмен...
Не думаю, что что-то может сильно ветвиться в partial_sort, уж больно стандартный алгоритм. Время работы O(sz1*log(sz2+sz3)).

DS>>Динамическое создание структур данных в C++ пока даже не предвидется.

E>Не совсем понятно зачем нужны динамически созданные структуры. Код-то пишется ещё ДО КОМПИЛЯЦИИ?
С установки может прийти от 1 до 15 потоков данных в double. Задача принять все активные потоки, и отсортировать данные по первому потоку.
Вариант 0. Динамически создать strct rec { doble r[n]; }; vector<rec> data;
n — имеется ввиду количество потоков данных. C++ этого не позволяет, так что остается либо разбазаривать память (в случае, если работают меньше 15 потоков):
Вариант 1. struct rec { double r[15]; }; vector<rec> data;
Либо поменять теплое и мягкое местами:
Вариант 2. struct data { vector<vector<double> > data; };
а это
E>> это параллельные массивы, что в свою очередь очень сомнительная практика
практика, может, и сомнительная. но пример я придумал.
E>Ну это к тому, что легко граблей напрогать, а как проверить напрогали ли граблей -- не ясно
lint и его производные дожны помочь. Но вот мне что-то подсказывает, что промахнуться мимо end все же проще.
Re[14]: Мама! А зачем все эти навороты в зоопарке? ;)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 06.08.09 22:19
Оценка:
Здравствуйте, Erop, Вы писали:

E>Ну типа ещё и пирожки печёт что ли?

E>Какие конкретно задачи будут лучше решаться-то? Есть какие-то неумозрительные примеры?

Напишите ваше решение на итераторах для задачи про лиги. Решение для range я привел выше
Автор: Erop
Дата: 07.08.09
.
Re[15]: ссылко
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 06.08.09 22:29
Оценка:
решение тут
Автор: Dmi3S
Дата: 07.08.09
. промахнулся.
Re[17]: Мама! А зачем все эти навороты в зоопарке? ;)
От: Erop Россия  
Дата: 06.08.09 23:17
Оценка:
Здравствуйте, Dmi3S, Вы писали:

DS>У нас всего 60 игроков. Надо в первую лигу запихнуть 20 лучших. В таком виде задача реализуется за один вызов partial_sort. Значит, нам осталось только собрать вместе 60 игроков, что мы и делаем, указывая в качестве второго range chain(liga2,liga3);


Есть такой известный алгоритм, которые позволяет итерировать несколько упорядоченных последовательностей так, словно это одна упорядоченная последовательность. Мне он известен под названием "N-путевое слияние"...

E>>Например, было бы логично потребовать, чтобы те, кого переброска не затронула, сохранили бы свою лигу... На слитой последовательности, IMHO, сделать это не так-то и просто.

DS>насколько я знаю, partial_sort не занимается лишними перестановками.
Да? А откуда partial_sort узнает, что перестановка между второй и третьей двадцатками "лишние"?
Как видишь, твой подход только запутывает...

DS>3 сортировки + 1 самописный алгоритм вместо вызова одной функции разбиения? Тогда давайте говорить за эффективность,

DS>количество кода, скорость написания и отладки.
3 сортировки вместо одной поверх объединённых регионов -- скорее всего будут шибко быстрее.
Самописный алгоритм нифига не самописный. Да и не сложный, к тому же..


DS>И, кстати, судя по частоте употребления слова "слияние", вы под ним что-то нехорошее подразумеваете. Что-то вроде копирования контейнеров. Этого нет. Под слиянеим понимается объединение двух ranges в один новый range.

Если ты хочешь обсудить меня, а не идеи о выгодности интервалов, то я так понимаю, что про интервалы уже всё ясно?

DS>По-подробнее пожалуйста. Потому как задачи (лиги,лукошки) эквивалентны, а ваши решения -- нет.

Да ладно, не эквивалентны. Пишем примерно такой цикл:
пока( худший из ещё не поменяных лучших хуже лучшего их ещё непоменяных худших ) 
    поменять (худшего из ещё непоменяных лучших и лучшего из ещё непоменяных худших )

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

DS>Не думаю, что что-то может сильно ветвиться в partial_sort, уж больно стандартный алгоритм. Время работы O(sz1*log(sz2+sz3)).


Ветвиться будет не там, в внутри объединённого диапазона...
Если partial_sort будет работать поверх объединённого интервала, как поверх интервала массива, или интервала списка, например, то будет много ненужных переходов между контейнерами => всяких лишних ненужных проверок на выходы за границы...
А если partial_sort будет как-то специализирован на тему объединённых диапазонов, то это просто обозначает, что задачу о трёх лигах решат авторы библиотеки, а не ты.

DS>С установки может прийти от 1 до 15 потоков данных в double. Задача принять все активные потоки, и отсортировать данные по первому потоку.

Нереальная задача. И как это ёксель-то написать смогли?

DS>Вариант 0. Динамически создать strct rec { doble r[n]; }; vector<rec> data;

DS>n — имеется ввиду количество потоков данных. C++ этого не позволяет, так что остается либо разбазаривать память (в случае, если работают меньше 15 потоков):
E>>> это параллельные массивы, что в свою очередь очень сомнительная практика
DS>практика, может, и сомнительная. но пример я придумал.

Глупый пример. Давным-давно придуманы эффективные реализации 2-хмерных массивов для С++, которые, в том числе, позволяют легко переставлять как строки, так и столбцы. Вот их и надо использовать...

Кстати, как планируется решать эту задачу на диапазонах?

DS>lint и его производные дожны помочь. Но вот мне что-то подсказывает, что промахнуться мимо end все же проще.

Ну ты же рекламируешь не то, что мимо "end не промахнёшься", с этим как раз более или менее всё понятно. А то, что есть всякие рульные новые фичи, которых у итераторов просто нет?

Я же спросил "зачем надо писать partial_sort( chein( v1, v2 ) )?"...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[15]: Мама! А зачем все эти навороты в зоопарке? ;)
От: Erop Россия  
Дата: 06.08.09 23:31
Оценка:
Здравствуйте, Dmi3S, Вы писали:

DS>Напишите ваше решение на итераторах для задачи про лиги. Решение для range я привел выше
Автор: Erop
Дата: 07.08.09
.


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

Но лучше ты расскажи, как так таки решить задачу при лиги на диапазонах?

Итак
есть три лиги, надо достойных собрать в первую, вытолкнув недостойных во вторую и третью, но при этом не допустить переходов между второй и третьей...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[18]: А сюда уже можно и не смотреть.
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 07.08.09 00:02
Оценка: -1
Здравствуйте, Erop, Вы писали:

E>Есть такой известный алгоритм, которые позволяет итерировать несколько упорядоченных последовательностей так, словно это одна упорядоченная последовательность. Мне он известен под названием "N-путевое слияние"...


N-путевым слиянием называется процесс объединения нескольких упорядоченных серий(т.е упорядоченных последовательностей) в одну. Используется в сортировке слиянием.
Алгоритм, позволюющий параллельно итерировать несколько последовательностей, называется for_each.
Давайте перед употреблением названий и терминов их хотя бы понимать.

E>Да? А откуда partial_sort узнает, что перестановка между второй и третьей двадцатками "лишние"?

partial_sort переставляет между двумя range. Первый range это liga1. Второй range это liga2+liga3. Есть мнениние что, во втором для partial_sort range взаимных перестановок не будет.
E>Как видишь, твой подход только запутывает...
Это не мой подход. Не надо мне ничего приписывать.

E>3 сортировки вместо одной поверх объединённых регионов -- скорее всего будут шибко быстрее.

Давайте без скорей всего, а с оценками в О-нотации. Для своего алгоритма я оценку привел.
E>Самописный алгоритм нифига не самописный. Да и не сложный, к тому же..
Хорошо. Если он есть в std или boost — можете его вызвать. Если нет — пишите.

E>Если ты хочешь обсудить меня, а не идеи о выгодности интервалов, то я так понимаю, что про интервалы уже всё ясно?

Как вас, так и "идеи о выгодности" я обсуждать не собираюсь.

E>Да ладно, не эквивалентны. Пишем примерно такой цикл:
пока( худший из ещё не поменяных лучших хуже лучшего их ещё непоменяных худших ) 
E>    поменять (худшего из ещё непоменяных лучших и лучшего из ещё непоменяных худших )

Три корзинки по 20 грибов. Собрать в одной лучшие из всех 60. На таком примитивном уровне обсуждения, задачи все еще не эквивалентны?

E>Просто в корзинках лучшый и худший ищется "методом взгляда",

"Метод взгляда" на полную корзинку не действует. Рентген сломался.
Кстати, как определять очередных лучших и худших среди грибов без рентгена? Случайно, не предварительной ли сортировкой?

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

Пожалуйста, не XZ, а код в студию. С оценкой времени выполнения.

E>Ветвиться будет не там, в внутри объединённого диапазона...

Блджад, вы до сих пор не прочитали даже презентацию?! Мдя. И что мы тут обсуждаем? Выдуманные вами интервалы и итераторы?

E>Если partial_sort будет работать поверх объединённого интервала, как поверх интервала массива, или интервала списка, например, то будет много ненужных переходов между контейнерами => всяких лишних ненужных проверок на выходы за границы...

Это ваши фантазии.
E>А если partial_sort будет как-то специализирован на тему объединённых диапазонов, то это просто обозначает, что задачу о трёх лигах решат авторы библиотеки, а не ты.
Это значит, что задача о грибах была придумана под конкретное решение -- вызов partial_sort.

DS>>С установки может прийти от 1 до 15 потоков данных в double. Задача принять все активные потоки, и отсортировать данные по первому потоку.

E>Нереальная задача. И как это ёксель-то написать смогли?
Видимо, читали документацию.

E>Глупый пример. Давным-давно придуманы эффективные реализации 2-хмерных массивов для С++, которые, в том числе, позволяют легко переставлять как строки, так и столбцы. Вот их и надо использовать...

Там было волшебное слово. Сортировка. Впрочем, с чтением у вас не очень, что и показывает следующий вопрос:
E>Кстати, как планируется решать эту задачу на диапазонах?

E>Ну ты же рекламируешь не то, что мимо "end не промахнёшься", с этим как раз более или менее всё понятно. А то, что есть всякие рульные новые фичи, которых у итераторов просто нет?

Блджад. Я ни чего не рекламирую. Я высказываю свою точку зрения. Подкрепляю аргументами. Пытаюсь придумать какие то примеры. А потом выясняется, что из двух собеседников один даже не в курсе, о чем говорим. Глазги берег.

E>Я же спросил "зачем надо писать partial_sort( chein( v1, v2 ) )?"...

Блджад, так писать _нельзя_. По определению partial_sort.
Re[11]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: jazzer Россия Skype: enerjazzer
Дата: 07.08.09 01:54
Оценка:
Здравствуйте, Dmi3S, Вы писали:

DS>>>s/MoveNext/popFront

DS>>>, то полученный результат ничего не напомнит?

J>>С прямым итератором это действительно так.

J>>А вот у двунаправленного итератора будет еще и MovePrev — ы? Аналогично для итератора с произвольным доступом.
DS>Я как бы хотел узнать, можно ли исходную конструкцию назвать итератором, и чем она отличается от range. В возможности добавления туда игр и девушек я не сомневался
Так я и ответил (курсивом).
Но диапазоны же мыслятся как замена всех итераторов, а не только прямых.

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

DS>Да, с использованием списков итерирование фактически невозможно. Это же начальные условия.
Ну так и смысл тогда убивать итераторы?

DS>Я вообще как-то плохо понимаю: такое ощущение, что все старательно подходят с молотком к новому шурупу, и делают соответствующие выводы.

Потому что изобретатель шурупа настаивает, что молотки больше не нужны.
А ему говорят, что молотки еще много где пригодятся.

DS>Неужели ни кому не нравится вот такая возможность:

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

DS>PS. Посмотрел на boost::zip_iterator. Сомневаюсь, что читаемый аналог второго примера влезет в экран.

Ну это как раз не проблема:
vector<double> vd;
vector<string> vs;
deque<int>     vi;
// sort the three in lockstep
sort(
  make_zip_iterator( make_tuple(vs.begin(), vd.begin(), vi.begin()) ),
  make_zip_iterator( make_tuple(vs.end(),   vd.end(),   vi.end()  ) )
);

Все вполне читаемо и всюду влезает.
Сам понимаешь, что написать версию make_zip_iterator с переменным числом параметров (просто скопировав интерфейс make_tuple), а потом упаковать пару make_zip_iterator в make_zip_range не проблема — тогда все вообще превратится в одну строчку.

Но конкретно этот пример компилироваться не будет, по другим причинам (это проблема со всеми итераторами, которые возвращают ad-hoc-прокси) — они по стандарту должны возвращать ссылку, а не что-либо еще, что фактически убивает возможность прокси-итераторов (похоже, о них просто не думали, когда писали требования в стандарте). Но это проблема конкретной спецификации, ее несколько раз пытались поменять уже, в т.ч. из буста. Это известная проблема, можешь почитать, например, здесь: http://lists.boost.org/Archives/boost/2004/07/68758.php, там же предложен пример, как это обойти.


З.Ы. Просто Александреску занимается экстремизмом: "Смерть итераторам, всё на диапазонах!", а ты как будто подозреваешь в аналогичном экстремизме нас "Смерть диапазонам, всё на итераторах!", хотя мы все на самом деле говорим: "Диапазоны будут отличным дополнением к итераторам".
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[12]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 07.08.09 03:46
Оценка:
Здравствуйте, jazzer, Вы писали:

DS>>Да, с использованием списков итерирование фактически невозможно. Это же начальные условия.

J>Ну так и смысл тогда убивать итераторы?
Избавиться от итерирования. Это имхо и было отправной точкой, судя по первым слайдам.

J>Потому что изобретатель шурупа настаивает, что молотки больше не нужны.

J>А ему говорят, что молотки еще много где пригодятся.
Я, конечно, не могу высказывать что-то от имени изобретателя, но кажется, что предложение было несколько иного рода. Предлагалось заменить гвозди с молотками на шурупы с отвертками. Врочем, это исключительно предположение. Да и материалов по теме пока мало. Только доки по D, да презентация.

DS>>Неужели ни кому не нравится вот такая возможность:

J>да нравится, нравится, разве я про нее хоть слово против сказал?
Не то чтобы против, но вот это заставило напрячь извилины

DS>>Что нового привносит данная концепция?
J>Имхо — ничего, если принимать во внимание существование Boost.Range.


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

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


DS>>PS. Посмотрел на boost::zip_iterator. Сомневаюсь, что читаемый аналог второго примера влезет в экран.


J>Ну это как раз не проблема:

J>
J>vector<double> vd;
J>vector<string> vs;
J>deque<int>     vi;
J>// sort the three in lockstep
J>sort(
J>  make_zip_iterator( make_tuple(vs.begin(), vd.begin(), vi.begin()) ),
J>  make_zip_iterator( make_tuple(vs.end(),   vd.end(),   vi.end()  ) )
J>);
J>

J>Все вполне читаемо и всюду влезает.
А корректная ли функция сравнения будет использована? Судя по презентации, сравниваются между собой только строки. Я, когда говорил об экране, намекал как раз на нехилое определение этой фунции.

J>Но конкретно этот пример компилироваться не будет, по другим причинам (это проблема со всеми итераторами, которые возвращают ad-hoc-прокси) — они по стандарту должны возвращать ссылку, а не что-либо еще, что фактически убивает возможность прокси-итераторов (похоже, о них просто не думали, когда писали требования в стандарте). Но это проблема конкретной спецификации, ее несколько раз пытались поменять уже, в т.ч. из буста. Это известная проблема, можешь почитать, например, здесь: http://lists.boost.org/Archives/boost/2004/07/68758.php, там же предложен пример, как это обойти.


И это уже 5 лет тянется? Мдя... Ну да ладно, мы пока о концепциях: в плане реализации, ranges вообще только в другом языке существуют.

J>З.Ы. Просто Александреску занимается экстремизмом: "Смерть итераторам, всё на диапазонах!",

Да, и это изрядно веселит . Очень каардинальная смена парадигмы для весомой части C++.

J> а ты как будто подозреваешь в аналогичном экстремизме нас "Смерть диапазонам, всё на итераторах!", хотя мы все на самом деле говорим: "Диапазоны будут отличным дополнением к итераторам".

Нет, ни кого не подозреваю. Я пытаюсь найти что-то новое, что можно легко сделать на диапазонах, и не очень комфортабельно на итераторах.

PS. Для ясности повторюсь. Мне просто понравилась идея и подход Александреску . Она (идея) пока что не кажется жизнеспособной, но от этого красивой быть не перестает.
Re[13]: s/каардинальная/кардинальная (-)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 07.08.09 03:53
Оценка:
Re[13]: Показалось.
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 07.08.09 04:57
Оценка:
DS>А корректная ли функция сравнения будет использована? Судя по презентации, сравниваются между собой только строки. Я, когда говорил об экране, намекал как раз на нехилое определение этой фунции.
Перечитал еще раз слайды. Ни где нет упоминания о том, каким именно способом сортируются zip-ы. Так что, думаю, мне показалось при первом чтении, что будет именно так.
Re[13]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: jazzer Россия Skype: enerjazzer
Дата: 07.08.09 05:05
Оценка:
Здравствуйте, Dmi3S, Вы писали:

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


DS>>>Да, с использованием списков итерирование фактически невозможно. Это же начальные условия.

J>>Ну так и смысл тогда убивать итераторы?
DS>Избавиться от итерирования. Это имхо и было отправной точкой, судя по первым слайдам.
Ну да, только он же и сам в конце презентации при обсуждении говорит, что его концепция не будет работать, если мы шли-шли по диапазону вперед, а потом вдруг решили повернуть назад.
Так что он и сам все прекрасно понимает.

J>>Потому что изобретатель шурупа настаивает, что молотки больше не нужны.

J>>А ему говорят, что молотки еще много где пригодятся.
DS>Я, конечно, не могу высказывать что-то от имени изобретателя, но кажется, что предложение было несколько иного рода. Предлагалось заменить гвозди с молотками на шурупы с отвертками. Врочем, это исключительно предположение. Да и материалов по теме пока мало. Только доки по D, да презентация.

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

DS>>>Неужели ни кому не нравится вот такая возможность:

J>>да нравится, нравится, разве я про нее хоть слово против сказал?
DS>Не то чтобы против, но вот это заставило напрячь извилины
DS>

DS>>>Что нового привносит данная концепция?
J>>Имхо — ничего, если принимать во внимание существование Boost.Range.

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

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

DS>А вот про это он промолчал
ну, это он на слайдах промолчал, а на видео ему кучу вопросов поназадавали на эту тему, и он практически со всем согласился.

DS>>>PS. Посмотрел на boost::zip_iterator. Сомневаюсь, что читаемый аналог второго примера влезет в экран.


J>>Ну это как раз не проблема:

J>>
J>>vector<double> vd;
J>>vector<string> vs;
J>>deque<int>     vi;
J>>// sort the three in lockstep
J>>sort(
J>>  make_zip_iterator( make_tuple(vs.begin(), vd.begin(), vi.begin()) ),
J>>  make_zip_iterator( make_tuple(vs.end(),   vd.end(),   vi.end()  ) )
J>>);
J>>

J>>Все вполне читаемо и всюду влезает.
DS>А корректная ли функция сравнения будет использована? Судя по презентации, сравниваются между собой только строки.
Я не знаю, что там у него в D.
Boost.Tuple сравниваются лексикографически (т.е. сначала первый элемент, если одинаковые, то второй, и т.д.)

DS>Я, когда говорил об экране, намекал как раз на нехилое определение этой фунции.

С чего ему быть нехилым? Как раз наоборот (не компилировал, пишу в браузере):
struct less_by_first_element
{
  template <class T>
  bool operator()(const T& lhs, const T& rhs) const {
    return std::less( lhs.get<0>(), rhs.get<0>() );
  }
};


DS>И это уже 5 лет тянется? Мдя... Ну да ладно, мы пока о концепциях: в плане реализации, ranges вообще только в другом языке существуют.

Ну да.
бустовцы уже представляли это дело комитету, примерно в таком виде:
http://www.boost.org/libs/iterator/doc/new-iter-concepts.html

DS>Нет, ни кого не подозреваю. Я пытаюсь найти что-то новое, что можно легко сделать на диапазонах, и не очень комфортабельно на итераторах.

Ну, все операции над диапазонами, где итераторы не являются основной вещью, а являются просто средством построить один диапазон из другого, в принципе, в итераторах не нуждаются, это просто деталь реализации. И зачастую есть способы сделать многие преобразования непосредственно, не переходя явно на уровень итераторов и обратно.

DS>PS. Для ясности повторюсь. Мне просто понравилась идея и подход Александреску . Она (идея) пока что не кажется жизнеспособной, но от этого красивой быть не перестает.

Ну это да, хотя радикально нового я не вижу, все это очень давно уже обсуждается.
Вот, например, Boost.RangeEx (еще не в официальной поставке):
http://lists.boost.org/Archives/boost/2009/02/148682.php
можно будет писать нечто вроде
container | boost::adaptors::filtered(_1==0) | | boost::adaptors::reversed
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[19]: А сюда уже можно и не смотреть.
От: Erop Россия  
Дата: 07.08.09 05:22
Оценка:
Здравствуйте, Dmi3S, Вы писали:

DS>Давайте перед употреблением названий и терминов их хотя бы понимать.

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

E>>Да? А откуда partial_sort узнает, что перестановка между второй и третьей двадцатками "лишние"?

DS>partial_sort переставляет между двумя range. Первый range это liga1. Второй range это liga2+liga3. Есть мнениние что, во втором для partial_sort range взаимных перестановок не будет.
Да? А на чём оно основано? Мы про аналог вот этого partial_sort

Rearranges the elements in the range [first,last), in such a way that the subrange [first,middle) contains the smallest elements of the entire range sorted in ascending order, and the subrange [middle,end) contains the remaining elements without any specific order.

говорим? AFAIK, выделенная фраза обозначает, что никаких гарантий рорядка в "хвосте" последовательности std::partial_sort НЕ ДАЁТ!
Если мне не изменяет память, то в STL есть ещё stable_partition и stable_sort, которые сохраняют порядок, но они делают не то. Кроме того они ещё и дороже...

E>>Как видишь, твой подход только запутывает...

DS>Это не мой подход. Не надо мне ничего приписывать.
Извини, "подход, который тебе нравится в этой задаче только запутывает" -- так хорошо?

E>>3 сортировки вместо одной поверх объединённых регионов -- скорее всего будут шибко быстрее.

DS>Давайте без скорей всего, а с оценками в О-нотации. Для своего алгоритма я оценку привел.
Да? Интересно какую?
AFAIK, у partial_sort асимптотическая сложность О( N ln N ), а у трёх sort -- то же O( N ln N ), а у N-путевого слияния сложность вообще линейная... Так что асимптота у них одинаковая. Вопрос в величине коэффициента и в том, насколько асимптота начинает работать при N = 20

E>>Самописный алгоритм нифига не самописный. Да и не сложный, к тому же..

DS>Хорошо. Если он есть в std или boost — можете его вызвать. Если нет — пишите.
А если он есть в тех библиотеках, которыми ПОЛЬЗУЮСЬ я?

E>>Да ладно, не эквивалентны. Пишем примерно такой цикл:
пока( худший из ещё не поменяных лучших хуже лучшего их ещё непоменяных худших ) 
E>>    поменять (худшего из ещё непоменяных лучших и лучшего из ещё непоменяных худших )

DS>Три корзинки по 20 грибов. Собрать в одной лучшие из всех 60. На таком примитивном уровне обсуждения, задачи все еще не эквивалентны?
Эквивалентны. Я же написал тебе одинаковое решение для обеих?
E>>Просто в корзинках лучшый и худший ищется "методом взгляда",
DS>"Метод взгляда" на полную корзинку не действует. Рентген сломался.
Тогда корзинка не может обеспечить random_access, и к обсуждаемой задаче прямого отношения не имеет
Ты правда, что ли, для того, чтобы найти "лучший из 20 грибов" их сортируешь? Надеюсь используешь алгоритм с ассимптотой O( N log N ), а не пузырёк какой-нибудь

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

DS>Пожалуйста, не XZ, а код в студию. С оценкой времени выполнения.

Сначала снизь тон... Ты же мне не платишь, что бы код требовать? Я понимаю, если не понятно, что нужно написать, но тут-то тебе наверное всё понятно?

E>>Ветвиться будет не там, в внутри объединённого диапазона...

DS>Блджад, вы до сих пор не прочитали даже презентацию?! Мдя. И что мы тут обсуждаем? Выдуманные вами интервалы и итераторы?

А я обсуждаю С ТОБОЙ, ТВОИ заверения, о том, что диапазоны рулят и дают мегавозможности. Собственно мне интересно ЗАЧЕМ ОНИ НУЖНЫ? Это же твоё мнение, что это надо и полезно? Ну вот и продемонстрируй, пожалуйста, чем это так полезно и хорошо и ЗАЧЕМ ЭТО НАДО?
Я видел слайды, там ничего содержательного про реализацию не видел. документ в PDF у меня не открывается. Если тебе кажется, что там есть что-то содержательное -- процитируй, пожалуйста...
Я не спорю с тем, что для всяких мест, где мы передаём ПАРУ итераторов, естественнее было бы передавать диапазон.
Но, обрати внимание, что в приведённом тобой, в качестве примера partial_sort в качестве аргумента передаётся ТРОЙКА итераторов. Так что, IMHO, как раз partial_sort выражать в терминах диапазонов довольно противоестественно

DS>Это ваши фантазии.

Ну поясни, как это будет работать-то?
Если вся мощь диапазонов сводится к тому, что можно сделать функцию chain, то на итераторах тоже можно. Просто будет две функции: chain_begin( TIterator1 begin1, TIterator1 end1, TIterator2 begin2 ) и chain_end( TIterator1 end1, TIterator2 begin2, TIterator2 end2 )...

Но, так как partial_sort требует random_access, то будет куча обращений вида *(chain_begin + shift), соответсвенно, в каждом таком обращении надо будет ветвиться для выбора между диапазонами...

DS>Это значит, что задача о грибах была придумана под конкретное решение -- вызов partial_sort.

Ну это полностью лишает твой пример доказательной силы.
1) Задача явно не очень актуальная и распространённая
2) На самом деле твой алгоритм её не решает, так как не обеспечивает непереход между второй и третьей лигами

DS>>>С установки может прийти от 1 до 15 потоков данных в double. Задача принять все активные потоки, и отсортировать данные по первому потоку.

E>>Нереальная задача. И как это ёксель-то написать смогли?
DS>Видимо, читали документацию.
К чему? К ненаписанному D?

E>>Глупый пример. Давным-давно придуманы эффективные реализации 2-хмерных массивов для С++, которые, в том числе, позволяют легко переставлять как строки, так и столбцы. Вот их и надо использовать...

DS>Там было волшебное слово. Сортировка.
Да, и что?
1) в ёкселе есть сортировка по любой комбинации столбцов
2) Реализация матрицы, в которой быстро вставляются/удаляются/сортируются, как строки, так и столбцы -- тема давно проработанная. Например, тут была статья...

DS>Впрочем, с чтением у вас не очень,

Э-э-э, вот от "подколок" такого типа и хотелось бы уйти. Я могу быть вообще маразматиком и моральным уродом с отрицательным IQ. Даже в этом случае, это никак не продемонстрирует достоинств подхода с диапазонвми.
Если ты хочешь обсуждать С++ -- давай обсуждать С++. А если ты хочешь обсудить меня, то я про себя и так всё знаю, в ты меня, скорее всего, совсем не знаешь, так что я лучше себя с женой и детьми обсужу, ты в этой области некомпетентен, IMHO...

DS>что и показывает следующий вопрос:

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

E>>Ну ты же рекламируешь не то, что мимо "end не промахнёшься", с этим как раз более или менее всё понятно. А то, что есть всякие рульные новые фичи, которых у итераторов просто нет?

DS>Пытаюсь придумать какие то примеры.
К сожалению, пока что, примеры не убеждают в полезности подхода. Во всяком случае меня...

E>>Я же спросил "зачем надо писать partial_sort( chain( v1, v2 ) )?"...

DS>Блджад, так писать _нельзя_. По определению partial_sort.
Ну я думаю, что ты понял, что я имел в виду.
Тем более, что вопрос я тебе уже выше по ветке задавал...
На всяк. случай:

Зачем нужно уметь писать: partial_sort(d, chain(v1, v2))?

Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[14]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 07.08.09 05:48
Оценка:
Здравствуйте, 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>

А вот это я почитаю когда высплюсь
Re[20]: А сюда уже можно и не смотреть.
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 07.08.09 06:08
Оценка: :)
E>Давай будем взаимовежливы? Либо снизь тон, и общайся, так, что с тобой будет приятно болтать о преимуществах диапазонов, либо я не буду с тобой вести беседу...

Предлагаю прекратить болтать.
Re[21]: Ты на вопрос-то ответь...
От: Erop Россия  
Дата: 07.08.09 09:16
Оценка:
Здравствуйте, Dmi3S, Вы писали:

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


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

Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[10]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Аноним  
Дата: 08.08.09 06:54
Оценка:
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… почему бы не объединить их в одну структуру?
Re[11]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Erop Россия  
Дата: 08.08.09 07:56
Оценка:
Здравствуйте, Аноним, Вы писали:

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


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

Но почему при этом: "Iterators Must Go"?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[11]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 08.08.09 08:00
Оценка:
Здравствуйте, Аноним, Вы писали:

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


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

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


Нет. Посмотрите на интерфейс range, описанный в презентации.
Ну и личное мнение: если ход мыслей Александреску кажется прозрачным при первом прочтении, значит я чего-то не понял.
Re[12]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Аноним  
Дата: 08.08.09 08:27
Оценка:
А>>Вот вам диапазоны, используйте на здоровье. Но зачем же итераторы выбрасывать?

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

Re[13]: BoostCon - Alexandrescu - Iterators Must Go (video)
От: Dmi3S Россия http://dmi3s.blogspot.com/
Дата: 08.08.09 08:37
Оценка:
Здравствуйте, Аноним, Вы писали:

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


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

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


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


А>

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


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