http://boostcon.blip.tv/

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:
J>http://boostcon.blip.tv/

... я так понял Андрей "поносит" STL ... ?
... или это такой тонкий способ пропиарить язык программирования D ... ?

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

R>Здравствуйте, jazzer, Вы писали:
J>>http://boostcon.blip.tv/

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

и то, и другое

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

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

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

В бусте сейчас идет горячее обсуждение, я кидал линк в "Философии программирования".

You will always get what you always got
  If you always do  what you always did

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

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

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

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

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

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

Здравствуйте, 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 я не использую в быту по причинам озвученным тёзкой, но это так — к слову.

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

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

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

Здравствуйте, 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 ).

ЗЫ. С моим английским такое качество аудио невоспринимаемо

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

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

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

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

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

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

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

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

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

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

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

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

DS>

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

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

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

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

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

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

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

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

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

DS>

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

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

Здравствуйте, 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, можно найти следующее вхождение.
Я привел несколько вполне себе логичных причин, и не вижу ни одной нелогичной.

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


DS>Я привел несколько вполне себе логичных причин, и не вижу ни одной нелогичной.
Нет, откусывание слева всего ненужного -- это совсем не тоже самое, что "некий диапазон, начинающийся с..."
А rfind, откусывает справа?

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

E>Ещё один хитрый вопрос -- что делать, если мне нужна позиция элемента, а не диапазон.
Range от текущего элемента до конца коллекции имхо.
E>Ну, например, если у меня есть список элементов, и коллекция курсоров в нём.
Нет никаких курсоров. Впрочем, у коллекции несуществующих курсоров можно вызвать find, получить range и запомнить его.
Хотя, я бы запоминал результат find от списка элементов.
E>Ну, типа я что-то редактирую в multiview редакторе и в каждом окне хочу иметь свой курсор?
Тогда кому нужна коллекция курсоров? Не проще ли у каждого view спросить его конктретный курсор^Wrange, front которого вернет ссылку на соответствующий элемент?

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

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

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

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

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

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

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

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

E>>А rfind, откусывает справа?
DS>Нет никакого rfind. Почитайте уже ссылку, что ли.
Она у меня не открывается. Видимо там PDF?

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

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

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

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

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

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

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

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

E>>>А rfind, откусывает справа?
DS>>Нет никакого rfind. Почитайте уже ссылку, что ли.
E>Она у меня не открывается. Видимо там PDF?
Да, pdf.