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

I>Ну, бывает и хуже, пишешь новый класс, и понимаешь что у тебя есть какое то множество, объявляешь его std::set<myenum>, написал половину класса и понимаешь что для одного из методов тебе важен порядок в какой было все считано, и меняешь set на vector, часть написанного кода остается а добавление меняется, вот это кстати минус, есть универсальный способ доступа к контейнерам, есть удаление, а вот одного и того же insert нету

Это действительно бывает и действительно намного хуже. Чтобы так не было программы стоит проектировать, однако

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

O>ЗЫ А меня от всего МФСшного, включая CList несварение желудка случается. Более отстойной библиотеки чем MFC пожалуй не найти.

Не-не-не! Пределов совершенству нет!!!

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

M>Тогда это ухудшение , потому что теряется универсальность. ПОпробуйте рассуждать в терминах , преимущества недостатки различных подходов. вместо "мне обычно хватает доступа по индекусу".

Ну так давно же известно, что универсальные решения в каждом конкретном случае хуже, зато они универсальные...

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


M>Согласен и ,тем не менее, при изменении end() контейнера ВСЕ range, допустим, полученые через MType::range = m.find(v); — тю-тю...
M>Мне что-то больше нравится с итератором вариант.

Что-то тут не так. Если тухнет end, то тухнут и все остальные итераторы вроде как...

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

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

M>>Тогда это ухудшение , потому что теряется универсальность. ПОпробуйте рассуждать в терминах , преимущества недостатки различных подходов. вместо "мне обычно хватает доступа по индекусу".

E>Ну так давно же известно, что универсальные решения в каждом конкретном случае хуже, зато они универсальные...

Восхитительный техничекий аргумент. Особенно перфоманс бенчмарки.

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

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

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

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

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

Нет , я по теме, я про итераторы.

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

E>Что-то тут не так. Если тухнет end, то тухнут и все остальные итераторы вроде как...

vector<int> v(10);
vector<int>::iterator first = v.begin(), middle = begin+v.size()/2, end = v.end(), last = end-1;
v.pop_back();

begin и middle валидны, end протух, last... как минимум, стал нечитаемым (v.end()==last), формально — протух.

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

К>begin и middle валидны, end протух, last... как минимум, стал нечитаемым (v.end()==last), формально — протух.
Гарантии нет. Вдруг был всего один элемент в векторе?
Кроме того, я не помню, есть ли гарантии для вектора в котором, скажем, 10 элементов.
Если помнишь, процитируй, что ли, как они формулируются. Чисто для полноты картины.

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

К>>begin и middle валидны, end протух, last... как минимум, стал нечитаемым (v.end()==last), формально — протух.
E>Гарантии нет. Вдруг был всего один элемент в векторе?
E>Кроме того, я не помню, есть ли гарантии для вектора в котором, скажем, 10 элементов.
E>Если помнишь, процитируй, что ли, как они формулируются. Чисто для полноты картины.

23.2.4.2 vector capacity [lib.vector.capacity]
5 Notes: Reallocation invalidates all the references, pointers, and iterators referring to the elements in the
sequence. It is guaranteed that no reallocation takes place during insertions that happen after a call to
reserve() until the time when an insertion would make the size of the vector greater than the size
specified in the most recent call to reserve().

23.2.4.3 vector modifiers [lib.vector.modifiers]
iterator erase(iterator position);
iterator erase(iterator first, iterator last);
3 Effects: Invalidates all the iterators and references after the point of the erase.

То есть, стандарт умалчивает, происходит ли переразмещение при удалениях.
Но можно предположить, что — нет, не происходит. Иначе бы последняя фраза звучала так: заведомо инвалидирует хвост, но и в голове тоже поберегись!

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

V>>>>Так и итераторов будет два, если функцию find обернуть — придётся всегда пару итераторов возвращать, тогда как range уже какбе пара итераторов.
M>>>чего й то???
V>>А как ты итератор на валидность проверишь?
O>Проверять в программе надо только входные данные, ибо они не под вашим контролем. Итератор должен _быть_ валиден, ибо код который вы пишете под вашим контролем. Или нет?
Не обязательно, если итератор будет потом использоваться, то его надо проверить на валидность посредством сравнения с концом.

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

V>>>>А как ты итератор на валидность проверишь?
M>>>Тупанул, да А как быть если возвращаешь, допустим, range, потом erase исходного контейнера. Что делать с end'ом в range??
К>>Неподходящее слово "валидность", перегруженное смыслами.
К>>Итераторы, — равно как и ссылки, указатели, диапазоны и прочие косвенности, — инвалидируются при некоторых изменениях контейнера.
К>>Однако, помимо невалидных, есть ещё и сигнальные значения.
К>>У указателей есть одно универсальное сигнальное значение — NULL, а также в роли сигнальных могут выступать указатели за конец массива (end()).
К>>Разыменовывать сигнальный указатель или итератор нельзя. Но если это end, то можно применять к нему адресную арифметику.
К>>В нашем случае, надо проверять не на валидность, а на сигнальность.
M>Согласен и ,тем не менее, при изменении end() контейнера ВСЕ range, допустим, полученые через MType::range = m.find(v); — тю-тю...
M>Мне что-то больше нравится с итератором вариант.
Это зависит в общем случае от контейнера, массив — возможно, лист — не обязательно.

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

V>Не обязательно, если итератор будет потом использоваться, то его надо проверить на валидность посредством сравнения с концом.

Вообще-то, валидность/невалидность итератора никак не связана с равенством/неравенством концу контейнера. Итератор, полученный с помощью end(), изначально валиден, и может стать невалидным впоследствии, в результате переаллокации, например. Невалидность итератора означает, что над ним нельзя выполнять никакие операции, в т.ч. сравнения, в т.ч. с концом. И проверить валидность итератора в общем случае нельзя, программа должна отслеживать валидность итераторов исходя из собственной логики.

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

V>>Не обязательно, если итератор будет потом использоваться, то его надо проверить на валидность посредством сравнения с концом.
R>Вообще-то, валидность/невалидность итератора никак не связана с равенством/неравенством концу контейнера. Итератор, полученный с помощью end(), изначально валиден, и может стать невалидным впоследствии, в результате переаллокации, например. Невалидность итератора означает, что над ним нельзя выполнять никакие операции, в т.ч. сравнения, в т.ч. с концом. И проверить валидность итератора в общем случае нельзя, программа должна отслеживать валидность итераторов исходя из собственной логики.
Ну если радеть за чистоту понятий то да

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

V>>Не обязательно, если итератор будет потом использоваться, то его надо проверить на валидность посредством сравнения с концом.
R>Вообще-то, валидность/невалидность итератора никак не связана с равенством/неравенством концу контейнера. Итератор, полученный с помощью end(), изначально валиден, и может стать невалидным впоследствии, в результате переаллокации, например. Невалидность итератора означает, что над ним нельзя выполнять никакие операции, в т.ч. сравнения, в т.ч. с концом. И проверить валидность итератора в общем случае нельзя, программа должна отслеживать валидность итераторов исходя из собственной логики.
Я имел ввиду под валидностью — валидность на разименовывание.

J>>Насчет практических случаев — да, использовал многажды, никаких нареканий к эффективности, ибо CRTP.
ND>Да, знаком, хотя сам таких финтов ни разу не писал. Действительно, оверхед будет нулевой. Виртуельные методы без VMT А в каких случаях использовали, Если не секрет? Только в Boost или использовали вообще как общий подход в работе с контейнерами?

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

что касается CRTP — штука мощная и полезная.

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

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