Итераторы

[xokc]

А как компилятор оптимизирует такой код?

Код

C++ (Qt)
std::list<int> src;
MyCollection dst;
 
for( int i = 0; i < src.size(); ++i )
    dst[ i ] = src[ i ];
 

Не зная что такое MyCollection, а именно какая реализация у него конструктора по умолчанию, конструктора копирования, перегруженных операторов [] и преобразования типа от int - могу только фантазировать, но в этом смысла не вижу. Без априорных знаний относительно реализации MyCollection оптимизировать такой код вообще бессмысленно. Может в момент создания элемента MyCollection производится n-кратное гарантированное удаление всех данных на всех серверах google, а тут буду влазить со своей оптимизацией доступа по индексу к std::list.
Если бы класс MyCollection писал я, то предусмотрел бы в нём метод MyCollection::loadFromList(const std::list<int> &src), чтобы другие люди не дописывали свои велосипеды, задумываясь о преждевременных оптимизациях. Возможно он был-бы статическим (как, например у QList<T> QList::fromStdList(const std::list<T> & list), возможно - нет.

[Old]

могу только фантазировать, но в этом смысла не вижу.

Фантазировать за компилятор? Я спрашивал, как этот код будет оптимизировать компилятор?
Реализация MyCollection закрытая, к вам пришла только собранная библиотека.
Ладно, не нужно писать как это оптимизируют все компиляторы, напишите пожалуйста про ваш основной компилятор.

[Igors]

А как их надо пересчитывать? А то из предыдущих постов не совсем понятно 

Та было, но зафлудили тему капитально с "оптимизацией", напомню

- был треугольник напр (0, 10, 11).  Если точка 1 (напр) удалена, то треугольник должен стать  (0, 9, 10)

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

[kamre]

Часто если немного подумать и взглянуть непредвзято - находятся куда лучшие решения чем залепухи std. Вот напр как в этой простой задачке 

Какое решение имеется ввиду? Вроде этого?

[xokc]

напишите пожалуйста про ваш основной компилятор.

Мне трудно с Вами общаться. Я же уже написал

Не зная что такое MyCollection ... могу только фантазировать.

Какого ответа Вы ещё от меня ждёте?
P.S. В этой теме больше отвечать не буду - Igors уже вполне справедливо негодует тему ему и так сильно зафлудили.

[Old]

Мне трудно с Вами общаться. Я же уже написал

Не зная что такое MyCollection ... могу только фантазировать.

Давайте с начала.
Я писал, что при последовательном доступе итераторы эффективней индексов. Вы написали, что все это фигня и современные компиляторы легко это как-то оптимизируют. Я написал вам, что не стоит без оглядки надеяться на компиляторы - они часто перестраховываются. Вы написали, что хорошо знаете свой инструмент. Теперь, я прошу вас показать как ваш компилятор оптимизирует мой пример (с оператором [] в отдельной библиотеке). Вы сказали, что вам трудно общаться. Почему?

P.S. В этой теме больше отвечать не буду - Igors уже вполне справедливо негодует тему ему и так сильно зафлудили.

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

[xokc]

Теперь, я прошу вас показать как ваш компилятор оптимизирует мой пример (с оператором [] в отдельной библиотеке).

Навру сам себе - всё таки отвечу. Но это точно мой последний пост тут. Мой компилятор не откомпилирует такой код, поскольку он не знает что такое MyCollection. Поэтому говорить об оптимизации того, чего не существует не могу.

[Old]

Навру сам себе - всё таки отвечу. Но это точно мой последний пост тут. Мой компилятор не откомпилирует такой код, поскольку он не знает что такое MyCollection. Поэтому говорить об оптимизации того, чего не существует не могу.

Ваш компилятор не умеет include?

Если бы класс MyCollection писал я, то предусмотрел бы в нём метод MyCollection::loadFromList(const std::list<int> &src), чтобы другие люди не дописывали свои велосипеды, задумываясь о преждевременных оптимизациях. Возможно он был-бы статическим (как, например у QList<T> QList::fromStdList(const std::list<T> & list), возможно - нет.

Вот еще показательная вещь: "чтобы другие люди не дописывали свои велосипеды..." я напишу свой.
В C++ есть std::copy, который хорошо это умеет делать, кстати он может копировать только часть коллекции в отличие от ваших методов loadFromList и fromStdList.
И программист C++ будет в первую очередь пытаться воспользоваться стандартными средствами и искренне удивится отсутствием итераторов в замен на чудо-методы.

[xokc]

Ваш компилятор не умеет include?

Мой компилятор умеет. Но где тут h файл, описывающий, что такое MyCollection не вижу ни я, ни мой компилятор. А Вы от меня хотите, чтобы я предсказал результат компиляции того, чего нет. Я так НЕ УМЕЮ. Говорю об этом третий раз.

И программист C++ будет в первую очередь пытаться воспользоваться стандартными средствами и искренне удивится отсутствием итераторов в замен на чудо-методы.

Вы очень легко ставите конкретные вопросы, а потом лихо экстраполируете ответы на них. Именно поэтому с Вами и трудно общаться. Я НЕ ЗНАЮ что такое тут MyCollection. И совершенно искренне признаюсь, что не умею угадывать наличие/отсутствие в неизвестной мне сущности (может это и не класс даже?) каких-либо методов исключительно по её названию.

[Old]

Я НЕ ЗНАЮ что такое тут MyCollection.

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

[Igors]

Часто если немного подумать и взглянуть непредвзято - находятся куда лучшие решения чем залепухи std. Вот напр как в этой простой задачке 

Какое решение имеется ввиду? Вроде этого?

Вот мой вариант (attach) который немного (?) напоминает Ваш В обоих случаях использование std/STL минимально - просто потому что оно здесь нафиг не нужно.

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

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

[Old]

И ничего я не выдумывал а взял наугад первое попавшееся из моих задач с полигонной геометрией.

Так оно такое именно из-за того, что вы кроме индексов больше ничем пользоваться не умеете.
Еще раз напомню про свой вариант задачи - пробуйте.

А хотите еще дам - и опять тот хваленый витиеватый синтаксис будет "ни пришей ни пристегни" - забивает людям голову и мешает думать

Код

C++ (Qt)
typedef std::vector<int>::iterator iter;
for( iter i = col.begin(); i != col.end(); ++i )
{
}
 
for(auto i = col.begin(); i != col.end(); ++i )
{
}
 
for( auto i : col )
{
}
 

Какой из этих вариантов для вас самый "витиеватый" и "головозабивающий"?

[Igors]

Так оно такое именно из-за того, что вы кроме индексов больше ничем пользоваться не умеете.
Еще раз напомню про свой вариант задачи - пробуйте.

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

[Old]

А где я его найду в теме полностью Вами же и замусоренной?

Ну так вы ее для этого создали... поэтому потрудитесь поискать.

И если Вы умеете это сделать "без индексов" - так покажите, а то дальше слов у Вас что-то дело не идет.

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

[Igors]

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

Ничего я не "придумывал", задача совершенно реальная. А вот Ваше предложение использовать др контейнер (напр список) от жизни далековато. Я Вам уже говорил что расход памяти резко возрастает, никакой реакции (впрочем не удивлен, это типично для теоретиков). Более того - как Вы подадите список в OpenGL? Там нужны линейные данные. Любой движок физики - то же самое.

Ну ладно, список так список. Да, тогда удаление легко и приятно, на то он и список. Так ведь др проблемы - напр как сериализовать/десериализовать? Хотите здесь показать подход std/stl - пожалуйста, как я уже говорил - не возражаю.