Название: Итераторы Отправлено: Igors от Апрель 12, 2013, 09:32 Добрый день
Неоднократно высказывалось мнение что использование итераторов - это круто, грамотно и все такое. Я лично этого мнения не разделяю и при первой возможности использую незатейливый оператор [] (ну конечно для контейнеров прямого доступа). На мой взгляд это короче и яснее. Аргументация в пользу итераторов не кажется мне убедительной - обычно приводятся примеры которые можно делать как угодно. А давайте возьмем задачку "чуть выше травы". Код Каждый Triangle хранит 3 индекса в контейнере mPoint, напр первый (0, 10, 15) и.т.д. Теперь пользователь каким-то образом выбрал несколько точек (известны их индексы) и заказал их удаление. Ну конечно надо не только замочить их в контейнере mPoint но и отредактировать mTriangle Прошу показать богатырскую силу итераторов на этом простом примере :) Спасибо Название: Re: Итераторы Отправлено: Old от Апрель 12, 2013, 09:53 Прошу показать богатырскую силу итераторов на этом простом примере :) Вы как всегда в крайности. :)Аргументация в пользу итераторов не кажется мне убедительной - обычно приводятся примеры которые можно делать как угодно. Какая нужна аргументация, если при последовательном перемещении по контейнеру с использованием индекса необходимо на каждой итерации вычислять эффективный адрес элемента, а итератор просто делает ++/-- указателя?А давайте возьмем задачку "чуть выше травы". Все как всегда. Задача точно подобрана. :)Каждый Triangle хранит 3 индекса в контейнере mPoint, напр первый (0, 10, 15) и.т.д. Давайте мы не будем хранить индексы. :) А то тут на нужен random-access к коллекции, а итераторы здесь как козе баян.Итераторы лучше и эффективней для последовательного доступа к коллекции. Кстати, значения printfом мы печатали доставая их, как раз, последовательно. ;) Название: Re: Итераторы Отправлено: alex312 от Апрель 12, 2013, 09:56 Неоднократно высказывалось мнение что использование итераторов - это круто, грамотно и все такое. Вы все напутали ! Грамотное использование итераторов - это круто, и все такое. :DНазвание: Re: Итераторы Отправлено: m_ax от Апрель 12, 2013, 10:59 О господи... Igors объявил войну итераторам))
https://www.youtube.com/watch?v=LcS5HR4w4Hg (https://www.youtube.com/watch?v=LcS5HR4w4Hg) или это? http://www.youtube.com/watch?v=Z6yP1huFq48 (http://www.youtube.com/watch?v=Z6yP1huFq48) Вспомнилось вот) Название: Re: Итераторы Отправлено: alex312 от Апрель 12, 2013, 11:35 а я вот начал ваять нечто, но все заглохло на инициализации массива треугольников.
Кто-то может выдать рабочий код для добавления треугольников в массив ? :o Название: Re: Итераторы Отправлено: Old от Апрель 12, 2013, 11:46 а я вот начал ваять нечто, но все заглохло на инициализации массива треугольников. Кто-то может выдать рабочий код для добавления треугольников в массив ? :o Новый стандарт есть? :) Код
Название: Re: Итераторы Отправлено: alex312 от Апрель 12, 2013, 12:17 Новый стандарт есть? :) Толи лыжи не едут, толи ... http://liveworkspace.org/code/cIG2U$4Название: Re: Итераторы Отправлено: Old от Апрель 12, 2013, 12:40 Толи лыжи не едут, толи ... http://liveworkspace.org/code/cIG2U$4 Код
Название: Re: Итераторы Отправлено: alex312 от Апрель 12, 2013, 12:41 Код
Название: Re: Итераторы Отправлено: Old от Апрель 12, 2013, 12:44 Название: Re: Итераторы Отправлено: alex312 от Апрель 12, 2013, 12:51 Код массив массивов и вектор массивов работают, вектор с простыми массивами не работает :o Название: Re: Итераторы Отправлено: m_ax от Апрель 12, 2013, 13:11 Код массив массивов и вектор массивов работают, вектор с простыми массивами не работает :o Да, не, нормально там всё работает) Для таких вложенных конструкций надо писать так: Код
Название: Re: Итераторы Отправлено: Alex Custov от Апрель 12, 2013, 13:26 Какая нужна аргументация, если при последовательном перемещении по контейнеру с использованием индекса необходимо на каждой итерации вычислять эффективный адрес элемента, а итератор просто делает ++/-- указателя? думаю, что в наилучшем случае для итератора i++ (инкремент индекса) будет на пару тактов быстрее, чем ++iter (инкремент итератора). Но это экономия на спичках, и вопрос в принципе несущественный. Название: Re: Итераторы Отправлено: alex312 от Апрель 12, 2013, 13:35 думаю, что в наилучшем случае для итератора i++ (инкремент индекса) будет на пару тактов быстрее, чем ++iter. Но это экономия на спичках, и вопрос в принципе несущественный. http://stackoverflow.com/questions/24886/is-there-a-performance-difference-between-i-and-i-in-cНазвание: Re: Итераторы Отправлено: alex312 от Апрель 12, 2013, 13:39 Да, не, нормально там всё работает) Там-то нормально, ты попробуй что-то сделать с Код
Название: Re: Итераторы Отправлено: Old от Апрель 12, 2013, 13:51 думаю, что в наилучшем случае для итератора i++ (инкремент индекса) будет на пару тактов быстрее, чем ++iter. Но это экономия на спичках, и вопрос в принципе несущественный. При инкременте индекса, что бы добраться до элемента, мы должны:* увеличить индекс на 1 * умножить индекс на размер элемента * получившееся смещение прибавить к базовому адресу вектора и это на каждой итерации. Итератор просто прибавит к указателю размер элемента. Название: Re: Итераторы Отправлено: m_ax от Апрель 12, 2013, 14:06 Да, не, нормально там всё работает) Там-то нормально, ты попробуй что-то сделать с Код
Название: Re: Итераторы Отправлено: xokc от Апрель 12, 2013, 14:32 При инкременте индекса, что бы добраться до элемента, мы должны: * увеличить индекс на 1 * умножить индекс на размер элемента * получившееся смещение прибавить к базовому адресу вектора и это на каждой итерации. Итератор просто прибавит к указателю размер элемента. Всё написанное верно только для частного случая, когда в качестве контейнера выступает что-то вроде вектора. В этом случае любой более-менее разумный компилятор догадается, что нужно п. 1-3 соптимизировать до инкремента указателя. И разницы в скорости не будет вообще. В общем же случае случаях необходимо - для индекса: * увеличить индекс на 1 * вызвать метод operator[] Для интератора ++it * вызвать метод operator++ Для итератора it++ * вызвать метод operator++ * вызвать конструктор копирования. И что в этом случае будет более оправданно с точки зрения скорости выполнения будет целиком зависеть от кривости рук программиста, написавшего реализации этих методов. Так что уж по поводу быстродействия спор бессмысленен. По сути вопроса. соглашусь с Igors - для меня безитераторный подход и компактнее и понятнее. Я бы вообще перегрузку операторов запретил бы раз и на всю жизнь. Название: Re: Итераторы Отправлено: Alex Custov от Апрель 12, 2013, 14:41 думаю, что в наилучшем случае для итератора i++ (инкремент индекса) будет на пару тактов быстрее, чем ++iter. Но это экономия на спичках, и вопрос в принципе несущественный. http://stackoverflow.com/questions/24886/is-there-a-performance-difference-between-i-and-i-in-cРечь шла о "индекс vs. итератор", дописал точнее. Название: Re: Итераторы Отправлено: Old от Апрель 12, 2013, 14:49 Всё написанное верно только для частного случая, когда в качестве контейнера выступает что-то вроде вектора. Так его и обсуждаем.В общем же случае случаях необходимо - для индекса: Покажите пожалуйста реализацию operatora[] для вектора, где не нужно будет делать * увеличить индекс на 1 * вызвать метод operator[] Цитировать * умножить индекс на размер элемента * получившееся смещение прибавить к базовому адресу вектора Название: Re: Итераторы Отправлено: Alex Custov от Апрель 12, 2013, 14:51 При инкременте индекса, что бы добраться до элемента, мы должны: * увеличить индекс на 1 * умножить индекс на размер элемента Зачем? Код: array[i] Итератор просто прибавит к указателю размер элемента. не просто, это вызов оператора operator++, что уже медленнее, чем просто инкремент индекса. А внутри operator++ делается тот же инкремент индекса или указателя на массив с внутренним представлением вектора. То есть в наихудшем случае есть расходы на вызов сложного оператора, плюс расходы на вызов begin() и end(). Название: Re: Итераторы Отправлено: Old от Апрель 12, 2013, 14:54 Зачем? array чем не подходит? А при чем здесь array?Мы говорим про адресную арифметику, которая будет применяться хоть в array, хоть в vector, хоть C-style array. Название: Re: Итераторы Отправлено: Alex Custov от Апрель 12, 2013, 14:55 А при чем здесь array? Это форум сделал курсив из обращения по индексу Название: Re: Итераторы Отправлено: Old от Апрель 12, 2013, 14:59 Это форум сделал курсив из обращения по индексу Код
Название: Re: Итераторы Отправлено: Alex Custov от Апрель 12, 2013, 15:04 Код
Зачем так сложно? По классике POD operator[] разворачивается в Код . P.S. отсюда интересная возможность писать Код
Название: Re: Итераторы Отправлено: Old от Апрель 12, 2013, 15:05 Зачем так сложно? По классике operator[] разворачивается в А в машинных командах и одна и другая запись разворачивается в то, что я написал. :)Код . Название: Re: Итераторы Отправлено: xokc от Апрель 12, 2013, 15:11 Всё написанное верно только для частного случая, когда в качестве контейнера выступает что-то вроде вектора. Так его и обсуждаем.Покажите пожалуйста реализацию operatora[] для вектора, где не нужно будет делать А в каком месте я утверждал, что для вектора operator[] нужно делать по другому?* умножить индекс на размер элемента * получившееся смещение прибавить к базовому адресу вектора Название: Re: Итераторы Отправлено: Old от Апрель 12, 2013, 15:21 А в каком месте я утверждал, что для вектора operator[] нужно делать по другому? Ну как же, вы написали что адресная арифметика понадобится только в частном случае. Хотя для вектора, итераторы для которого мы и обсуждаем, она будет необходима всегда для доступа по индексу.Название: Re: Итераторы Отправлено: alex312 от Апрель 12, 2013, 15:56 примерный набросок - http://liveworkspace.org/code/cIG2U
Название: Re: Итераторы Отправлено: Igors от Апрель 13, 2013, 06:03 По поводу инкремента. Когда-то аккуратно/грамотно было так
Код И это действительно работало быстрее, пусть и немного. Но время это давным-давно миновало, поэтому ссылаться на мифическую скорость итератора неуместно Название: Re: Итераторы Отправлено: Old от Апрель 13, 2013, 06:13 Когда-то аккуратно/грамотно было так Это и сейчас грамотней и эффективней. :)И это действительно работало быстрее, пусть и немного. Но время это давным-давно миновало, поэтому ссылаться на мифическую скорость итератора неуместно Это и сейчас работает быстрее. Никуда эти времена не миновали и не минуют никогда. Не будет никогда процессоров, выполняющих некоторые команды за 0 тактов. Больше команда, больше тактов. И не важно, что это всего несколько тактов на итерацию.Название: Re: Итераторы Отправлено: Igors от Апрель 13, 2013, 06:40 А то тут на нужен random-access к коллекции, а итераторы здесь как козе баян. Ага, оказывается не всегда итераторы - обязательно лучшее решение.Давайте мы не будем хранить индексы. :) А что, адреса? Это имеет далеко идущие последствия - они должны быть неперемещаемы, для таких элементов как QPont3D размер данных возрастает вдвое. Ну хорошо, используйте др контейнер на Ваш вкус - может там покажете силу итераторов.примерный набросок - http://liveworkspace.org/code/cIG2U Ну что сказать - очень современный код, я так не напишу (хотя читал о всех средствах что Вы используете). Однако функционал безобразен- copy/paste кода печати удручает, это ф-ция - был треугольник напр (0, 10, 11). Если точка 1 (напр) удалена, то треугольник должен стать (0, 9, 10) - erase (в цикле) и find дорогие операции. Тормоза будут уже на 10K данных (1k) удаляемых - а ведь это детский объем. А там ведь легко получается пресловутое O(n) Однако при всем этом alex312 - единственный кто подтвердил свой подход кодом. Поэтому прошу считать мои замечания конструктивной критикой. Название: Re: Итераторы Отправлено: Old от Апрель 13, 2013, 06:47 Ага, оказывается не всегда итераторы - обязательно лучшее решение. Ах эти крайности, крайности, крайности....Конечно не всегда, в программирование не бывает обязательно лучших решений. Вы не читаете мои посты? В одном из них я написал в каких случаях итераторы эффективней. Название: Re: Итераторы Отправлено: Igors от Апрель 13, 2013, 08:59 Не будет никогда процессоров, выполняющих некоторые команды за 0 тактов. Больше команда, больше тактов. И не важно, что это всего несколько тактов на итерацию. Если мы так умело считаем такты, то объясните почему совершенно провальная по скорости реализация не вызвала у Вас никакой реакции? Ведь можно сделать на порядок быстрее - и код не длиннее.Мне кажется потому что голова занята не задачей и не поиском лучшего решения, а отеми цацками-пецками (типа std::array <int, 3>). И чем более утонченные средства применяются - тем хуже результат :) Название: Re: Итераторы Отправлено: Old от Апрель 13, 2013, 09:22 Если мы так умело считаем такты, то объясните почему совершенно провальная по скорости реализация не вызвала у Вас никакой реакции? Ведь можно сделать на порядок быстрее - и код не длиннее. А какая у меня должна быть реакция? Человек захотел сделать реализацию с итераторами, мне нужно было его поругать? :)Мне кажется потому что голова занята не задачей и не поиском лучшего решения, а отеми цацками-пецками (типа std::array <int, 3>). А я никакие задачи не решаю и никаких решений не ищу.И чем более утонченные средства применяются - тем хуже результат Мне очень жаль, что у вас так происходит. Но, с другой стороны, никто и не заставляет ими пользоваться.Название: Re: Итераторы Отправлено: Igors от Апрель 15, 2013, 12:03 А я никакие задачи не решаю и никаких решений не ищу. Так приходит старость..Название: Re: Итераторы Отправлено: RedDog от Апрель 15, 2013, 12:35 В нижеприведенном коде, итераторы быстрее в 2 раза (в релизе)
Код Что интересно, в дебаге все наоборот. Название: Re: Итераторы Отправлено: Old от Апрель 15, 2013, 14:01 Так приходит старость.. Да.Сейчас вообще занялся идиотизмом, снова пишу код для Commodore 64 (процессор 6502). Ассемблер only, считаю такты, генерирую pre-calc таблицы, оптимизирую память... :) В общем, занимаюсь детством и мне совсем не интересно участвовать в столь грандиозной теме, как: "Языку C++ скоро 30 лет, а мы только сейчас добрались до главы при итераторы". Название: Re: Итераторы Отправлено: xokc от Апрель 15, 2013, 14:14 В нижеприведенном коде, итераторы быстрее в 2 раза (в релизе) Неитераторный код-то неадекватен. Тут нужно было int tmp[1000000] вместо std::vector<int> tmp использовать. И боюсь, что в этом случае результаты в релизе бы совпали с точностью до погрешности измерений.А вообще, опять же в таких примитивных случаях многое зависит от оптимизаторских способностей компилятора, а вовсе не от использования итераторов. Название: Re: Итераторы Отправлено: Old от Апрель 15, 2013, 14:16 Тут нужно было int tmp[1000000] вместо std::vector<int> tmp использовать. Почему?Название: Re: Итераторы Отправлено: RedDog от Апрель 15, 2013, 14:39 Неитераторный код-то неадекватен. Тут нужно было int tmp[1000000] вместо std::vector<int> tmp использовать. И боюсь, что в этом случае результаты в релизе бы совпали с точностью до погрешности измерений. Исходя из первого поста - необходимо обходить контейнер либо итератором либо через индекс.А вообще, опять же в таких примитивных случаях многое зависит от оптимизаторских способностей компилятора, а вовсе не от использования итераторов. Ну разница в 2+ раза думаю включает в себя не только оптимизацию компилятора, но и оптимизацию алгоритма.Название: Re: Итераторы Отправлено: xokc от Апрель 15, 2013, 14:51 Тут нужно было int tmp[1000000] вместо std::vector<int> tmp использовать. Почему?Исходя из первого поста - необходимо обходить контейнер либо итератором либо через индекс. Тогда уж обходите контейнер через int *tmpPtr = tmp.data() и дальше используйте tmpPtr.Ну разница в 2+ раза думаю включает в себя не только оптимизацию компилятора, но и оптимизацию алгоритма. Оптимизация компилятором и состоит именно в том, чтобы свести эти алгоритмы к одному и тому же.А вообще про производительность примитивных итераторов много сказано тут http://www.viva64.com/ru/b/0093/ Автор там приходит ко вполне очевидному выводу - в релизе нет никакой разницы между такими примитивными проверками. Любой разумный комплилятор сведет ваш код к одному и тому же. Там же еще одна интересная мысль "не пришло ли то самое страшное время, когда в программе появляются свои собственные специализированные классы строк, массивов и так далее..." Но это - тема для совсем другой дискуссии. Название: Re: Итераторы Отправлено: Old от Апрель 15, 2013, 14:55 о чём тут вообще рассуждать? Здесь я с вами полностью согласен. :)Название: Re: Итераторы Отправлено: RedDog от Апрель 15, 2013, 15:01 xokc зачем ставить все с ног на голову? В первом посте сказано: либо итераторы, либо через []. В рамках этого я и привел пример. Если по твоему рассуждать, то можно вообще все на указателях замутить, тогда разницы не будет нигде.
А инкримент итератора и указателя для данного примера(имхо), по скорости равнозначен. Название: Re: Итераторы Отправлено: xokc от Апрель 15, 2013, 15:43 xokc зачем ставить все с ног на голову? В первом посте сказано: либо итераторы, либо через []. В рамках этого я и привел пример. Если смотреть на первый пост, то речь там вообще шла не о переборе значений, а о "демонстрации мощи итераторов" при удалении элемента. Так что от темы мы тут все уже далеко уклонились :)Если по твоему рассуждать, то можно вообще все на указателях замутить. Я именно так всегда и стараюсь делать, а не применять итераторы всюду, лишь бы это было модно. Да и вектора стараюсь применять только там, где мне это удобнее чем просто массив на стеке.А инкримент итератора и указателя для данного примера(имхо), по скорости равнозначен. Где я утверждал обратное?А вообще от этой темы я уже устал. По моему тут уже давно всем всё ясно и дискуссия идёт просто ради дискуссии. Название: Re: Итераторы Отправлено: Igors от Апрель 16, 2013, 11:24 А вообще от этой темы я уже устал. По моему тут уже давно всем всё ясно и дискуссия идёт просто ради дискуссии. К сожалению да, пустопорожний "подсчет тактов" хотя это даже есть в библии писаной более 10 лет назад.Если смотреть на первый пост, то речь там вообще шла не о переборе значений, а о "демонстрации мощи итераторов" при удалении элемента. Так что от темы мы тут все уже далеко уклонились :) С демонстрацией мощи совсем плохо. Только один показал STL-реализацию которая, увы, проигрывает лобовому решению на С раз в 10. Но он хотя бы показал, а остальные вообще отделываются общими (иногда назидательными) фразами и упорно переводят разговор на такты ("игра в эксперта"). Куда же делась вся "концептуальность" когда появилась простенькая и очень банальная задачка? :) Название: Re: Итераторы Отправлено: alex312 от Апрель 16, 2013, 11:35 Только один показал STL-реализацию которая, увы, проигрывает лобовому решению на С раз в 10. Где "эталонное" решение, где тесты производительности ?Название: Re: Итераторы Отправлено: RedDog от Апрель 16, 2013, 12:08 Прошу прощения, мои тесты работают одинаково по скорости, ибо в итераторном тесте вкралась ошибочка begin() надо для первого цикла вызывать каждый раз, А он вызывается только один раз.
Название: Re: Итераторы Отправлено: Igors от Апрель 16, 2013, 12:47 Прошу прощения, мои тесты работают одинаково по скорости, ибо в итераторном тесте вкралась ошибочка begin() надо для первого цикла вызывать каждый раз, А он вызывается только один раз. Ну может и не совсем одинаково, но разница настолько незначительна что нет смысла заниматься такой оптимизацией. То давно известно, тема о другом - вроде использование итераторов "более идейно" и позволяет писать лучший код. Однако пока никакого подтверждения этому я не увидел.Где "эталонное" решение, где тесты производительности ? Конечно выложу, не вопрос. Но давайте сравнивать одинаковый функционал (пока у Вас индексы не пересчитаны). Исправьте, тогда сравним Название: Re: Итераторы Отправлено: Alex Custov от Апрель 16, 2013, 13:16 Ну может и не совсем одинаково, но разница настолько незначительна что нет смысла заниматься такой оптимизацией. То давно известно, тема о другом - вроде использование итераторов "более идейно" и позволяет писать лучший код. Однако пока никакого подтверждения этому я не увидел. Идея простая - идея универсальности. Есть абстрактная коллекция, есть итератор для неё, который начинается с begin() и заканчивается на end(). Во всех случаях ты пишешь один код. Название: Re: Итераторы Отправлено: alex312 от Апрель 16, 2013, 13:37 Конечно выложу, не вопрос. Но давайте сравнивать одинаковый функционал (пока у Вас индексы не пересчитаны). Исправьте, тогда сравним А как их надо пересчитывать? А то из предыдущих постов не совсем понятно ???Название: Re: Итераторы Отправлено: Old от Апрель 16, 2013, 14:33 хотя это даже есть в библии писаной более 10 лет назад. Ссылочку не подскажете на вашу библию. ;)Куда же делась вся "концептуальность" когда появилась простенькая и очень банальная задачка? :) Хотите задачку, давайте. :)Давайте мы точечки не будем хранить в векторе, а будем их хранить в связанном списочке, что бы можно было их быстро вставлять/удалять. Будьте любезны, исполните решение на индексах. И сравним с, как вы сказали, лобовым решение на C. :) "подсчет тактов" Классное слово "такт". Еще прикольно произносится "Сигурни Уивер", можете их со словом "такт" чередовать. :)... разговор на такты Название: Re: Итераторы Отправлено: Old от Апрель 16, 2013, 14:59 тема о другом - вроде использование итераторов "более идейно" и позволяет писать лучший код. Однако пока никакого подтверждения этому я не увидел. Ща, попробую на пальцах показать: Скажите пожалуйста, а какой код из этих более идейный и лучший?Код
Код
Вот первый это итераторы, а второй индексы. Не больше не меньше. Никаких скрытых магических свойств (которые вы ждете) у итераторов нет. Грусть. Название: Re: Итераторы Отправлено: xokc от Апрель 16, 2013, 15:35 Ща, попробую на пальцах показать: Скажите пожалуйста, а какой код из этих более идейный и лучший? Поскольку критериев "идейности" и "лучшести" кода не приведено, значит, используя метод экспертной оценки, и себя в качестве эксперта считаю, что лучше код на индексах - при прочих равных по быстродействию он короче и понятней. Название: Re: Итераторы Отправлено: Old от Апрель 16, 2013, 15:43 Поскольку критериев "идейности" и "лучшести" кода не приведено, значит, используя метод экспертной оценки, и себя в качестве эксперта считаю, что лучше код на индексах - при прочих равных по быстродействию он короче и понятней. На самом деле эти примеры не равнозначны, то что современные компиляторы сами (за программиста) научились приводить второй пример к первому, это только их заслуга. По моему, надеяться на инструменты не совсем правильно. "Если программа работает медленно, мы лучше подождем новое железо или более умный компилятор, но не будем оптимизировать свой код".Название: Re: Итераторы Отправлено: kamre от Апрель 16, 2013, 17:25 Конечно выложу, не вопрос. Но давайте сравнивать одинаковый функционал (пока у Вас индексы не пересчитаны). Исправьте, тогда сравним Имеется ввиду что-то вроде такого (http://liveworkspace.org/code/cIG2U$40) или без использования дополнительной памяти?Код
Цитировать Before: (0, 1, 2), (0, 2, 3), (2, 3, 1) (2, 4, 3), (4, 3, 1), (4, 2, 3) (0, 2, 4), (0, 1, 4), (5, 2, 1) (5, 4, 3), (0, 2, 5), (1, 3, 5) After: (2, 1, 0), (3, 2, 1), (0, 1, 3) Название: Re: Итераторы Отправлено: xokc от Апрель 16, 2013, 18:11 По моему, надеяться на инструменты не совсем правильно. "Если программа работает медленно, мы лучше подождем новое железо или более умный компилятор, но не будем оптимизировать свой код". Если я точно знаю как ведет себя компилятор, зачем я буду работать за него? Его нормочас однозначно дешевле моего. Надеюсь Вы уже не пишите x = y << 1 вместо x = y * 2?Название: Re: Итераторы Отправлено: Old от Апрель 16, 2013, 18:19 Надеюсь Вы уже не пишите x = y << 1 вместо x = y * 2? А что в этом плохого? Или эта запись вызывает у вас какие-то сложности?Если я точно знаю как ведет себя компилятор, зачем я буду работать за него? А вы всегда точно знаете, как будет оптимизировать компилятор? Если вы думаете да, то сильно ошибаетесь. Компилятор частенько перестраховывается.Как правильно показал Igors, программисты перестали считать такты, они стали считать часы и деньги. Поэтому текстовый редактор сейчас весит сотни мегабайт и для работы требует 4 ядра/4 гига. Название: Re: Итераторы Отправлено: xokc от Апрель 16, 2013, 18:54 А что в этом плохого? Или эта запись вызывает у вас какие-то сложности? Плохого в этом много. Сами понимаете, что приведен примитивный пример. В общем случае чтение кода ухудшается на порядки и вероятность пропустить ошибку в таком коде несоизмеримо выше.А вы всегда точно знаете, как будет оптимизировать компилятор? Если вы думаете да, то сильно ошибаетесь. Компилятор частенько перестраховывается. Да, я знаю свои инструменты достаточно хорошо, чтобы понять где стоит заморочиться низкоуровневой оптимизацией, а где довериться компилятору. Кроме того, злоупотребление низкоуровневыми конструкциями может и ухудшить результат оптимизации, например, приведет к "неузнаванию" компиляторами ситуаций когда можно применить вектроную арифметику или распараллеливание.Как правильно показал Igors, программисты перестали считать такты, они стали считать часы и деньги. Странно, я вроде бы на протяжении всей этой темы старался показать, что "считаю такты". Так что этот камень - не в мой огород. Кроме того мне задачу ставят так: сделай то-то, с таким-то качеством, за такое-то время и такие-то деньги. Если я буду считать только первые 2 пункта я рискую запороть два последних.Название: Re: Итераторы Отправлено: Old от Апрель 16, 2013, 19:11 Кроме того, злоупотребление низкоуровневыми конструкциями может и ухудшить результат оптимизации, например, приведет к "неузнаванию" компиляторами ситуаций когда можно применить вектроную арифметику или распараллеливание. А я и не предлагаю чем-то злоупотреблять, тем более низкоуровневыми конструкциями. Я начал отказываться от использования ассемблера при выходе Пентиума (хотя активно его использовал начиная с 8086), после появления 64-битной платформы - отказался полностью (на PC).Но здесь нет низкоуровневых конструкций, здесь есть индексы или указатели. Да, я знаю свои инструменты достаточно хорошо, чтобы понять где стоит заморочиться низкоуровневой оптимизацией, а где довериться компилятору. А как компилятор оптимизирует такой код?Код
Название: Re: Итераторы Отправлено: xokc от Апрель 17, 2013, 08:31 А как компилятор оптимизирует такой код? Код
Не зная что такое 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), возможно - нет. Название: Re: Итераторы Отправлено: Old от Апрель 17, 2013, 08:39 могу только фантазировать, но в этом смысла не вижу. Фантазировать за компилятор? Я спрашивал, как этот код будет оптимизировать компилятор?Реализация MyCollection закрытая, к вам пришла только собранная библиотека. Ладно, не нужно писать как это оптимизируют все компиляторы, напишите пожалуйста про ваш основной компилятор. Название: Re: Итераторы Отправлено: Igors от Апрель 17, 2013, 11:01 А как их надо пересчитывать? А то из предыдущих постов не совсем понятно ??? Та было, но зафлудили тему капитально с "оптимизацией", напомню- был треугольник напр (0, 10, 11). Если точка 1 (напр) удалена, то треугольник должен стать (0, 9, 10) А можно и ширше поставить вопрос: не только итераторы, а и использование STL вообще (вызовы std, функторы и.т.п. - все что есть в Вашей реализации). Я не утверждаю что этим не надо пользоваться, но эффективность считаю сильно преувеличенной. Часто если немного подумать и взглянуть непредвзято - находятся куда лучшие решения чем залепухи std. Вот напр как в этой простой задачке :) Название: Re: Итераторы Отправлено: kamre от Апрель 17, 2013, 11:42 Часто если немного подумать и взглянуть непредвзято - находятся куда лучшие решения чем залепухи std. Вот напр как в этой простой задачке :) Какое решение имеется ввиду? Вроде этого (http://www.prog.org.ru/index.php?topic=24541.msg174732#msg174732)?Название: Re: Итераторы Отправлено: xokc от Апрель 17, 2013, 12:07 напишите пожалуйста про ваш основной компилятор. Мне трудно с Вами общаться. Я же уже написалНе зная что такое MyCollection ... могу только фантазировать. Какого ответа Вы ещё от меня ждёте?P.S. В этой теме больше отвечать не буду - Igors уже вполне справедливо негодует тему ему и так сильно зафлудили. Название: Re: Итераторы Отправлено: Old от Апрель 17, 2013, 12:24 Мне трудно с Вами общаться. Я же уже написал Давайте с начала.Не зная что такое MyCollection ... могу только фантазировать. Я писал, что при последовательном доступе итераторы эффективней индексов. Вы написали, что все это фигня и современные компиляторы легко это как-то оптимизируют. Я написал вам, что не стоит без оглядки надеяться на компиляторы - они часто перестраховываются. Вы написали, что хорошо знаете свой инструмент. Теперь, я прошу вас показать как ваш компилятор оптимизирует мой пример (с оператором [] в отдельной библиотеке). Вы сказали, что вам трудно общаться. Почему? ;) P.S. В этой теме больше отвечать не буду - Igors уже вполне справедливо негодует тему ему и так сильно зафлудили. Эта тема была им создана для флуда и задача придумана специальная. По условию задачи хранятся индексы элементов и человек просит передалать это на итераторах, когда уже есть готовые индексы. И моя задача со связанным списком проигнорирована поэтому. Индексы туда прикрутить не очень получиться.Название: Re: Итераторы Отправлено: xokc от Апрель 17, 2013, 13:00 Теперь, я прошу вас показать как ваш компилятор оптимизирует мой пример (с оператором [] в отдельной библиотеке). Навру сам себе - всё таки отвечу. Но это точно мой последний пост тут. Мой компилятор не откомпилирует такой код, поскольку он не знает что такое MyCollection. Поэтому говорить об оптимизации того, чего не существует не могу.Название: Re: Итераторы Отправлено: Old от Апрель 17, 2013, 13:14 Навру сам себе - всё таки отвечу. Но это точно мой последний пост тут. Мой компилятор не откомпилирует такой код, поскольку он не знает что такое 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++ будет в первую очередь пытаться воспользоваться стандартными средствами и искренне удивится отсутствием итераторов в замен на чудо-методы. Название: Re: Итераторы Отправлено: xokc от Апрель 17, 2013, 14:29 Ваш компилятор не умеет include? :) Мой компилятор умеет. Но где тут h файл, описывающий, что такое MyCollection не вижу ни я, ни мой компилятор. А Вы от меня хотите, чтобы я предсказал результат компиляции того, чего нет. Я так НЕ УМЕЮ. Говорю об этом третий раз.И программист C++ будет в первую очередь пытаться воспользоваться стандартными средствами и искренне удивится отсутствием итераторов в замен на чудо-методы. Вы очень легко ставите конкретные вопросы, а потом лихо экстраполируете ответы на них. Именно поэтому с Вами и трудно общаться. Я НЕ ЗНАЮ что такое тут MyCollection. И совершенно искренне признаюсь, что не умею угадывать наличие/отсутствие в неизвестной мне сущности (может это и не класс даже?) каких-либо методов исключительно по её названию.Название: Re: Итераторы Отправлено: Old от Апрель 17, 2013, 14:36 Я НЕ ЗНАЮ что такое тут MyCollection. Да не важно в этом примере, что там за коллекция. Смысл в том, что компилятор будет дергать оператор [] этой коллекции каждую итерацию, а оператор [] будет честно вычислять адрес запрашиваемого элемента, тоже каждую итерацию. И ничего компилятор с этим сделать не сможет.Название: Re: Итераторы Отправлено: Igors от Апрель 17, 2013, 14:36 Часто если немного подумать и взглянуть непредвзято - находятся куда лучшие решения чем залепухи std. Вот напр как в этой простой задачке :) Какое решение имеется ввиду? Вроде этого (http://www.prog.org.ru/index.php?topic=24541.msg174732#msg174732)?Эта тема была им создана для флуда и задача придумана специальная. По условию задачи хранятся индексы элементов и человек просит передалать это на итераторах, когда уже есть готовые индексы. И моя задача со связанным списком проигнорирована поэтому. Индексы туда прикрутить не очень получиться. Уж кто здесь нафлудил - так это Вы :) И ничего я не выдумывал а взял наугад первое попавшееся из моих задач с полигонной геометрией. А хотите еще дам - и опять тот хваленый витиеватый синтаксис будет "ни пришей ни пристегни" - забивает людям голову и мешает думатьНазвание: Re: Итераторы Отправлено: Old от Апрель 17, 2013, 14:44 И ничего я не выдумывал а взял наугад первое попавшееся из моих задач с полигонной геометрией. Так оно такое именно из-за того, что вы кроме индексов больше ничем пользоваться не умеете.Еще раз напомню про свой вариант задачи - пробуйте. А хотите еще дам - и опять тот хваленый витиеватый синтаксис будет "ни пришей ни пристегни" - забивает людям голову и мешает думать Код
Какой из этих вариантов для вас самый "витиеватый" и "головозабивающий"? :) Название: Re: Итераторы Отправлено: Igors от Апрель 17, 2013, 16:59 Так оно такое именно из-за того, что вы кроме индексов больше ничем пользоваться не умеете. А где я его найду в теме полностью Вами же и замусоренной? :) И если Вы умеете это сделать "без индексов" - так покажите, а то дальше слов у Вас что-то дело не идет.Еще раз напомню про свой вариант задачи - пробуйте. Название: Re: Итераторы Отправлено: Old от Апрель 17, 2013, 17:11 А где я его найду в теме полностью Вами же и замусоренной? :) Ну так вы ее для этого создали... поэтому потрудитесь поискать.И если Вы умеете это сделать "без индексов" - так покажите, а то дальше слов у Вас что-то дело не идет. Ну вот, а как все хорошо начиналось. Придумали задачу, решением которой хотели всех впечатлить, а небольшое изменение условия и все рассыпалось.Ну подумайте еще, а я потом вам свои мысли расскажу, и по вашему решению с индексами в том числе. :) Название: Re: Итераторы Отправлено: Igors от Апрель 17, 2013, 19:07 Придумали задачу, решением которой хотели всех впечатлить, а небольшое изменение условия и все рассыпалось. Ничего я не "придумывал", задача совершенно реальная. А вот Ваше предложение использовать др контейнер (напр список) от жизни далековато. Я Вам уже говорил что расход памяти резко возрастает, никакой реакции (впрочем не удивлен, это типично для теоретиков). Более того - как Вы подадите список в OpenGL? Там нужны линейные данные. Любой движок физики - то же самое.Ну ладно, список так список. Да, тогда удаление легко и приятно, на то он и список. Так ведь др проблемы - напр как сериализовать/десериализовать? Хотите здесь показать подход std/stl - пожалуйста, как я уже говорил - не возражаю. Название: Re: Итераторы Отправлено: Old от Апрель 17, 2013, 19:18 А вот Ваше предложение использовать др контейнер (напр список) от жизни далековато. Почему? Вовсе нет. Он на таком же расстоянии как и ваш.Я Вам уже говорил что расход памяти резко возрастает, никакой реакции (впрочем не удивлен, это типично для теоретиков). Да вы что? Но меня это совершенно не пугает по моим требованиям нам нужна скорость при управлении точками, память вторична.Это сложно понять парню, который знает только индексы. У него все в это упирается. Более того - как Вы подадите список в OpenGL? Там нужны линейные данные. Ни каких OpenGL, только Software render, только хардкор.Так ведь др проблемы - напр как сериализовать/десериализовать? У вас и с этим проблемы? Сожалею.Хотите здесь показать подход std/stl - пожалуйста, как я уже говорил - не возражаю. Я никому ничего доказывать не собирался, это вы создали тему, что бы нас всех поразить своим кодом. Но, в который раз, не вышло.Название: Re: Итераторы Отправлено: Alex Custov от Апрель 17, 2013, 19:37 А в машинных командах и одна и другая запись разворачивается в то, что я написал. :) Забыл ответить. Не в это, т.к. операция *(array + i) при использовании оптимизации уровня O2 проходит за одну команду ассемблера, в отличие от того, что ты написал: Код
Код
Название: Re: Итераторы Отправлено: Old от Апрель 17, 2013, 20:06 Забыл ответить. Не в это, т.к. операция *(array + i) при использовании оптимизации уровня O2 проходит за одну команду ассемблера, в отличие от того, что ты написал: Это он хорошо оптимизировал. :)Код
Он простые примеры может и в Код: xor eax, eax А вот если ты цикл добавишь, то увидишь: Код: movl %eax, (%esp,%eax,4) Название: Re: Итераторы Отправлено: Alex Custov от Апрель 17, 2013, 20:21 хоть с vec, хоть *(vec+i). Разницы между первым и вторым нет, я же сразу написал. Речь шла о том, что доступ по индексу - это не та сложная конструкция, что ты написал. При должном уровне оптимизации она разворачивается в одну команду, даже в цикле (gcc 4.7): Код
Название: Re: Итераторы Отправлено: Old от Апрель 17, 2013, 20:51 Разницы между первым и вторым нет, я же сразу написал. Речь шла о том, что доступ по индексу - это не та сложная конструкция, что ты написал. При должном уровне оптимизации она разворачивается в одну команду, даже в цикле (gcc 4.7): Усложни пример.У меня gcc 4.8, я привел ассемблерную команду, которая делает то, что я написал. И это сишные массивы, а с коллекциями все похуже. Попробуй с оператором []. Название: Re: Итераторы Отправлено: Old от Апрель 18, 2013, 08:36 Где с 2000 года не
Посмотрел. Более того - как Вы подадите список в OpenGL? Там нужны линейные данные. Это кто вам такое сказал? :)Название: Re: Итераторы Отправлено: Igors от Апрель 18, 2013, 16:47 Я никому ничего доказывать не собирался, А тогда чему посвящены Ваши многочисленные посты в этой теме? :) Показать что Вы непререкаемый авторитет в машинном коде? Ну тогда Вы тем более должны понимать что программисту-практику очень редко нужно подсчитывать такты и вообще совать хобот в машинный код. Ему важно оценить выигрыш от возможной переделки кода - а он здесь, как ни крути, ничтожен. Чего же толочь воду в ступе? :)это вы создали тему, что бы нас всех поразить своим кодом. Но, в который раз, не вышло. Почему "поразить"? Как Вы замечали, я пишу несколько старомодно, вот мне было интересно как ту же задачу будут решать молодые, продвинутые и/или очень знающие. А вдруг я занимаюсь "изобретением велосипеда"? (что вполне возможно). Что же Вам не нравится? Что решения Вы не показали? Ну так моей вины в этом нет, я ж Вам не мешал. И ни к чему советовать мне заменить эту задачу другой - она не то что надо обходить.Название: Re: Итераторы Отправлено: Old от Апрель 18, 2013, 16:52 вот мне было интересно как ту же задачу будут решать молодые, продвинутые и/или очень знающие. Это придумки. ;)Итераторы - настолько примитивная вещь, что любой желающий понимает где они выгодны, а где нет просто прочитав 1 главу своей библию 10-летней давности (итераторы в несколько раз старше этой книги). :) А вот это действительно важно. Становиться понятно почему везде векторы и индексы. Ответьте если не сложно: Цитировать Более того - как Вы подадите список в OpenGL? Там нужны линейные данные. Это кто вам такое сказал? :)И куда именно вы подаете данные в OpenGL? Название: Re: Итераторы Отправлено: Igors от Апрель 19, 2013, 07:03 И куда именно вы подаете данные в OpenGL? Я использую в основном glVertexPointer, в отдельных случаях glDrawArraysА вот это действительно важно. Становиться понятно почему везде векторы и индексы. Типа "А почему бы не использовать др контейнеры/структуры данных? Тогда удаление может быть быстрее и легче". Ну так Вы же понимаете что этот выбор определяется очень многими причинами и удобство удаления - только один из резонов (возможно десятый или двадцатый по важности). Подобные предложения "изменить архитектуру приложения" в угоду частной задаче выглядят весьма легковесно (этим часто грешит m_ax :))Название: Re: Итераторы Отправлено: Old от Апрель 19, 2013, 07:40 Ну так Вы же понимаете что этот выбор определяется очень многими причинами и удобство удаления - только один из резонов (возможно десятый или двадцатый по важности). Ну я вам еще подскажу одно "удобство" - это скорость добавления (это наверное тридцатый по важности момент).Что же мы имеем: у нас появилась скорость при добавлении и скорость при удалении. Хотелось бы узнать остальные (теперь уже важные) причины выбора вектора. Если они конечно есть. :) Название: Re: Итераторы Отправлено: Igors от Апрель 20, 2013, 09:11 Ну я вам еще подскажу одно "удобство" - это скорость добавления (это наверное тридцатый по важности момент). Я Вам отвечал на это по меньшей мере трижды, больше не буду. Эффект "плохая задача". Утверждается что лучше вообще делать не так, долгие (и совершенно бесполезные) выяснения причин и.т.д. А в действительности задача "плоха" только тем что в 1 строчку решения нет, надо чуть-чуть подумать. И это частенько не нравится - как же так, с нашим отличным владением "auto" и др - все должно решаться с пол-пинка. Вот и флудим - то о тактах, то о хранении адресов, то еще о чем - думать-то лень :)Что же мы имеем: у нас появилась скорость при добавлении и скорость при удалении. Хотелось бы узнать остальные (теперь уже важные) причины выбора вектора. Если они конечно есть. :) Название: Re: Итераторы Отправлено: Old от Апрель 20, 2013, 09:30 Я Вам отвечал на это по меньшей мере трижды, больше не буду. Эффект "плохая задача". Утверждается что лучше вообще делать не так, долгие (и совершенно бесполезные) выяснения причин и.т.д. А в действительности задача "плоха" только тем что в 1 строчку решения нет, надо чуть-чуть подумать. И это частенько не нравится - как же так, с нашим отличным владением "auto" и др - все должно решаться с пол-пинка. Вот и флудим - то о тактах, то о хранении адресов, то еще о чем - думать-то лень :) Ага, я другого ответа не ожидал. :) Реальных то аргументов нет.Ну тогда я вам расскажу. Вектор (а точнее непрерывный участок памяти) изумительно подходит для хранения статических данных, никаких издержек с памятью не будет. На этом его преимущества и заканчиваются. Как только появляется задача "работу работать" вектор сразу становиться не эффективен и очень затратен, причем по всем показателям: у него наихудшая скорость добавления/удаления элементов + память начинается фрагментироваться (ну вы судя по темам на этом форуме с этим сталкивались не раз :) ). А теперь давайте возьмем реальную модель точек так на 10000 и посчитаем, сколько раз и какой объем данных будет перемещен при добавлении/удалении нескольких точек в вектор (не забудем пересчитать номера индексов в векторе треугольников). И станет ясно, что использовать вектор для этого по меньшей мере глупо. Про партикловые движки и векторы я вообще промолчу, но это наверно сложная тема для вас. Поэтому, вы и прикрываете свой не профессионализм, мнимой "необходимостью", а аргументировать это не можете, аргументов просто нет. :) А в действительности задача "плоха" только тем что в 1 строчку решения нет, надо чуть-чуть подумать Камень к себе в огород? :)Вот именно, что там где нужно подумать, вы этого не делаете, а берете "решение" из примеров интернет-курсов "OpenGL за 21 урок", а потом придумываете алгоритмы для героического обхода всех их недостатков и проблем. Название: Re: Итераторы Отправлено: Igors от Апрель 20, 2013, 17:01 Поэтому, вы и прикрываете свой не профессионализм, мнимой "необходимостью", а аргументировать это не можете, аргументов просто нет. :) :) Непрофессионализм - это когда человек судит совершенно не зная ни предметной области, ни подробностей проекта/задачи, а только исходя из ложного впечатления что он-то уж точно старше и опытнее. Все в той или иной мере повторяют эту ошибку.В действительности же в подавляющем большинстве случаев 3D модель - весьма стабильная "сущность" и операции удаления/добавления там крайне редки. Ну вот я дам Вам модель чайника, что Вы будете там удалять? Изуродуете чайник - и на этом дело кончится. Добавление - тем более, откуда возьмете геометрию? Ну может в "organic" моделерах (SDS) - там да, все динамично, но это узкая/специфичная область. Да и вообще - что это за (скажем так, "малодушный") уход от задачи? По-вашему выходит, мол, хранить индексы плохо, давайте этого всячески избегать? Такой подход лишен оснований, наоборот, хранение адресов часто порицается. Так что не надо тут вилять. Про партикловые движки ... Напротив, они мне очень интересны, и я предлагал обсудить одну из таких задач, там реально трудная постановка. Впрочем не знаю что Вы имеете ввиду, может разговор о разных движках. Название: Re: Итераторы Отправлено: Old от Апрель 20, 2013, 17:28 В действительности же в подавляющем большинстве случаев 3D модель - весьма стабильная "сущность" и операции удаления/добавления там крайне редки. Ну вот я дам Вам модель чайника, что Вы будете там удалять? Изуродуете чайник - и на этом дело кончится. Добавление - тем более, откуда возьмете геометрию? Ну может в "organic" моделерах (SDS) - там да, все динамично, но это узкая/специфичная область. Это в вашем мирке они "в подавляющем большинстве случаев" статичны. :) Только не понятно, для чего было предлагать написать алгоритм для удаления точки у статической модели?Давайте мы возьмем поверхность с ландшафтом и будем обстреливать ее снарядами: хочу воронки, разрушение холмов и прочие ямы. По-вашему выходит, мол, хранить индексы плохо, давайте этого всячески избегать? Это из чего выходит? :)Я поставил под сомнение обязательное использование векторов для хранения геометрии при использовании OpenGL. Есть более эффективные контейнеры для работы, например: связанные списки, деки, деки с указателями. И их спокойно можно использовать с OpenGL, но вот только индексы пойдут не со всеми. Такой подход лишен оснований, наоборот, хранение адресов часто порицается. Кем порицается, вами? Для меня это не показатель. ;)Если у вас есть реальные причины использования вектора - назовите их, иначе давайте закончим эту тему. Вы только юлите и выкручиваетесь, это становиться скучным. Название: Re: Итераторы Отправлено: alex312 от Апрель 20, 2013, 19:02 Наваял решение, критикуйте ::)
Код
Название: Re: Итераторы Отправлено: Igors от Апрель 21, 2013, 10:04 Давайте мы возьмем поверхность с ландшафтом и будем обстреливать ее снарядами: хочу воронки, разрушение холмов и прочие ямы. Если интересно я расскажу как решаются такие задачи :)Наваял решение, критикуйте ::) Ну Вы просто "развязали синтаксический террор" :) Как Вы представляете себе поддержку такого кода? "Хммм... ну ладно, что-то написано, как-то работает и слава богу". А если заклинит - в которой лямбде искать? :) И это еще здесь я хорошо знаю задачу и сразу понял что Вы делаете в принципе.Как у Вас со скоростью? Можно сравнить с вариантом kamre или моим - насколько я помню, у меня время удаления 5-7 миллисекунд. Ну и общий вопрос - стОит ли так писать? Помогает ли std? Мнение старого ретрограда - нет, только мешает. Не короче, не выразительнее и код не быстрее. Название: Re: Итераторы Отправлено: Old от Апрель 21, 2013, 10:06 Если интересно я расскажу как решаются такие задачи :) Не интересно, я сильно сомневаюсь, что у вас есть подобные знания, а чайники выводить я в детстве отлюбил. ;)Ладно, разговор про векторы и OpenGL для себя считаю закрытым. Название: Re: Итераторы Отправлено: alex312 от Апрель 21, 2013, 14:52 Ну Вы просто "развязали синтаксический террор" :) Спасибо за комплимент ::)Как Вы представляете себе поддержку такого кода? "Хммм... ну ладно, что-то написано, как-то работает и слава богу". А если заклинит - в которой лямбде искать? :) И это еще здесь я хорошо знаю задачу и сразу понял что Вы делаете в принципе. Если вы думаете что ваш код читается на одном дыхании, то вы глубоко заблуждаетесь . А если заклинит - то есть тесты и отладчики.Как у Вас со скоростью? Можно сравнить с вариантом kamre или моим - насколько я помню, у меня время удаления 5-7 миллисекунд. Сравнивал по скорости с вашим вариантом - мой отстает примерно в 2 раза, но мой вариант не использует дополнительной памяти.Ну и общий вопрос - стОит ли так писать? Помогает ли std? Да, именно так и стоит всегда писать если скорость исполнения достаточная.Не короче, не выразительнее и код не быстрее. Теперь по краткости и выразительности.1. Мой код 34 строки, ваш - 37 (код, который непосредственно относится к решению задачи). 2. В моем коде явно используется 1 цикл, в вашем 5, причем один вложенный. (Это про читаемость и понимаемость) 3. Ваш код гвоздями прибит к вектору, мой код может использовать и списки. Может для вас это не важно, но многие оценят. (если подправить функцию печати трегольников, но ведь это вспомогательная функция) Код
Название: Re: Итераторы Отправлено: Old от Апрель 21, 2013, 15:25 4. Если в качестве входных данных подсунуть не валидные индексы, то не портит по тихому память. :)
Название: Re: Итераторы Отправлено: Igors от Апрель 21, 2013, 16:35 Спасибо за комплимент ::) Я уважаю что вы отстояли Ваши взгляды кодом (это бывает редко, обычно одни слова) и мне не хотелось бы вступать в перепалку. Поэтому просто неск замечаний - надеюсь по делу- скорость. Вы говорите вдвое, это приемлемо. Но судя по коду Вы удаляете всего неск точек а я 10К. Сообщите что у Вас в этом случае. - binary_search + upper_bound. Мне кажется можно обойтись одним lower_bound - (заманчивая) общность - ну вряд ли std::distance даст приемлемую скорость напр для std::list. Да и зачем тогда индексы если данные неперемещаемы? 4. Если в качестве входных данных подсунуть не валидные индексы, то не портит по тихому память. :) То палка о двух концах - провалимся если индекс удаления валидный но встречается дважды Название: Re: Итераторы Отправлено: Old от Апрель 21, 2013, 17:02 То палка о двух концах - провалимся если индекс удаления валидный но встречается дважды Не знаю куда кто провалится, но я про вот это чудо:Код И если у kamre мы хотя бы поймаем assert в операторе [], то у вас в варианте он молча затрет что захочет. P.S. Пример преждевременной оптимизации во всей красе. ;) Вы хоть assert'ом проверяйте. Название: Re: Итераторы Отправлено: Igors от Апрель 21, 2013, 17:45 P.S. Пример преждевременной оптимизации во всей красе. ;) Вы хоть assert'ом проверяйте. Да какие глубокие мысли :) А так чем будете проверять? Код
Название: Re: Итераторы Отправлено: Old от Апрель 21, 2013, 17:56 А так чем будете проверять? А что вы тут хотите проверить?Код
Название: Re: Итераторы Отправлено: alex312 от Апрель 21, 2013, 18:14 - скорость. Вы говорите вдвое, это приемлемо. Но судя по коду Вы удаляете всего неск точек а я 10К. Сообщите что у Вас в этом случае. - При 10к точек, мой вариант 0.94с, ваш 0.25с.- binary_search + upper_bound. Мне кажется можно обойтись одним lower_bound - Без binary_search не обойтись, потому что при использовании xxx_bound нельзя однозначно опеделить отсутствие элемента в контейнере. ( конкретно lower_bound выдает указатель на начало контейнера при отсутствующем элементе) Название: Re: Итераторы Отправлено: Akon от Апрель 22, 2013, 11:44 Нужно понимать, что итераторы в первую очередь предназначены не для того, чтобы быть альтернативой индексации, а для декларации интерфейса доступа к элементам контейнера. Т.о., интераторы позволяют работать с любым контейнером (который их поддерживает), т.е. достигается абстракция контейнера, что крайне желательно на практике.
Название: Re: Итераторы Отправлено: Igors от Апрель 22, 2013, 12:04 А так чем будете проверять? А что вы тут хотите проверить?Код
- При 10к точек, мой вариант 0.94с, ваш 0.25с. Ну хорошо, допустим по каким-то причинам использование доп памяти запрещено. Что за причины - хз, ее расход не больше 20% от исходного объема. Ну ладно, нельзя так нельзя. Но и в этом случае я не вижу необходимости хоть каких-то функторов/лямбд и.т.п. Почему бы не решить простейшими базовыми средствами языка? Сделать ф-цию с нормальным человеческим именем напр - Без binary_search не обойтись, потому что при использовании xxx_bound нельзя однозначно опеделить отсутствие элемента в контейнере. ( конкретно lower_bound выдает указатель на начало контейнера при отсутствующем элементе) Код И очевидное удаление элементов из массива - можно размазывать сопли с remove_if (copy_if) а лучше простым и ясным for Название: Re: Итераторы Отправлено: Old от Апрель 22, 2013, 12:08 При таких данных std-вариант будет "молча работать неправильно". Это не его вина (junk in - junk out), но не надо намекать что он якобы "более надежен" :) Ваш вариант молча убивает память - ошибка в коде.Для std-варианта вместо вектора индексов удаляемых точек нужно просто использовать набор (std::set). Это еще один вид контейнеров. :) Название: Re: Итераторы Отправлено: Old от Апрель 22, 2013, 12:10 можно размазывать сопли с remove_if (copy_if) а лучше простым и ясным for Я думаю двоишникам по программированию и цикл for не ясный, давайте лучше if и goto. :)Название: Re: Итераторы Отправлено: Igors от Апрель 22, 2013, 12:39 Ваш вариант молча убивает память - ошибка в коде. А чего же Вы забыли добавить "при некорректных входных данных"? :) И чего не вдаетесь в анализ что может случиться с любой реализацией в этом случае ?Я думаю двоишникам по программированию и цикл for не ясный, давайте лучше if и goto. :) А Вам не кажется что цикл for давным-давно имел все достоинства новоиспеченной лямбды? :) Нужно понимать, что итераторы в первую очередь предназначены не для того, чтобы быть альтернативой индексации, а для декларации интерфейса доступа к элементам контейнера. Т.о., интераторы позволяют работать с любым контейнером (который их поддерживает), т.е. достигается абстракция контейнера, что крайне желательно на практике. Ах как удобно повторять написанное в книжке :) Не спорю, концептуально это красиво. Но давайте копнем чуть глубже на том же живом примере. Вот выше утверждалось что с copy_if код пригоден как для вектора, так и для списка. Возможно "работать будет" - но вот делать будет совсем не то что нужно. Чего же мы перемещаем все элементы списка при удалении некоторых? Зачем тогда список если адреса элементов уплывают? Грамотно удалять из списка его методом remove_if или erase в цикле. Но ни то ни другое не обобщается на линейные контейнеры как вектор. Вот и закончилась "концептуальная красота/общность" :) Название: Re: Итераторы Отправлено: Old от Апрель 22, 2013, 12:44 А чего же Вы забыли добавить "при некорректных входных данных"? :) И чего не вдаетесь в анализ что может случиться с любой реализацией в этом случае ? Вы и читаете не очень?Вот что я писал в посте #93: 4. Если в качестве входных данных подсунуть не валидные индексы, то не портит по тихому память. :) Какие слова здесь не понятны - спрашивайте.А Вам не кажется что цикл for давным-давно имел все достоинства новоиспеченной лямбды? :) :) Почитайте пожалуйста про "Лямбда-функции и выражения (http://ru.wikipedia.org/wiki/C%2B%2B11#.D0.9B.D1.8F.D0.BC.D0.B1.D0.B4.D0.B0-.D1.84.D1.83.D0.BD.D0.BA.D1.86.D0.B8.D0.B8_.D0.B8_.D0.B2.D1.8B.D1.80.D0.B0.D0.B6.D0.B5.D0.BD.D0.B8.D1.8F)"Как можно сравнивать циклы и функции? Название: Re: Итераторы Отправлено: Akon от Апрель 22, 2013, 14:28 Цитировать Ах как удобно повторять написанное в книжке Не спорю, концептуально это красиво. Но давайте копнем чуть глубже на том же живом примере. Вот выше утверждалось что с copy_if код пригоден как для вектора, так и для списка. Возможно "работать будет" - но вот делать будет совсем не то что нужно. Чего же мы перемещаем все элементы списка при удалении некоторых? Зачем тогда список если адреса элементов уплывают? Грамотно удалять из списка его методом remove_if или erase в цикле. Но ни то ни другое не обобщается на линейные контейнеры как вектор. Вот и закончилась "концептуальная красота/общность" Полагаете, STL столько существует ради концептуальной красоты? :D Вот вы ставите под сомнение некоторые фундаментальные вещи, только потому, что они, возможно, плохо подходят для решения ваших частных задач... А вот у меня задача - отсортировать контейнер. Как я по-вашему должен ее решить? А вот у меня есть некий компоновщик (паттерн), и мне нужно обойти всех парентов, начиная с текущего элемента и заканчивая топовым (т.е. имеем контейнер в виде дерева и нужно дойти до корня). Как я по-вашему должен ее решить? А если я захочу закэшировать результат обхода в линейном контейнере? Это мои реальные задачи, столь же "глубокие", как и ваши.Название: Re: Итераторы Отправлено: alex312 от Апрель 22, 2013, 14:43 Но и в этом случае я не вижу необходимости хоть каких-то функторов/лямбд и.т.п. Почему бы не решить простейшими базовыми средствами языка? Because We can \o/ ;DА если серьезно, то и лямбды и функторы - это базовые средства языка (может уже и не простейшие, но и не сложные). Основной их плюс в том что их можно объявить локально максимально близко к месту использования. И очевидное удаление элементов из массива - можно размазывать сопли с remove_if (copy_if) а лучше простым и ясным for Еще раз про сопли - в вашем коде 5 циклов, в моем 1.Цитата: Igors Но давайте копнем чуть глубже на том же живом примере. Вот выше утверждалось что с copy_if код пригоден как для вектора, так и для списка. Возможно "работать будет" - но вот делать будет совсем не то что нужно. А давайте вы немного подумаете, и все таки попытаетесь понять что мир программирования не ограничивается Вашими задачами. Я веду разработку под 4 платформы одновременно (PC-Win7, PC-Ubuntu, Cortex-A-Linux, STM32F4/F1). Многие функции у них пересекаются. У меня есть довольно большие куски кода которые работают на каждой из платформ. Поэтому я вам говорю : оптимально - это не всегда быстро. Название: Re: Итераторы Отправлено: Igors от Апрель 23, 2013, 07:16 По поводу "моих" задач - да бог с Вами, разве это "задача"? Это чисто техническая вещь которая может возникнуть в любой предметной области, хоть в том же Model-View которое (почему-то) использует индексы
А если серьезно, то и лямбды и функторы - это базовые средства языка (может уже и не простейшие, но и не сложные). И что, это уже круто? Если std::transform, copy_if и.т.п.- это уже не цикл, а "лучше". А мне кажется это просто снобизм/фетишизм. Я испытываю теплые чувства к лямбде со времен AutoLisp, задолго до ее появления здесь. Но надо знать меру. Обратите внимание что обычно стоит в теле лямбды - что-то однострочное. Тогда действительно выходит компактно/красиво. А у Вас? Увидев Ваши transform/copy_if я еще ничего не могу понять - мне надо найти функтор. Это мудрено, надо учесть std::bind и std::placeholder что Вы накрутили. Ладно, наконец прорвался, но имя отсутствует (безликий оператор ()) что он делает - хз. Ваш код прямо-таки кричит "смотрите как много я знаю", но разбираться с ним никто не захочет (включая тех кто здесь с Вами согласен).Основной их плюс в том что их можно объявить локально максимально близко к месту использования. ... Еще раз про сопли - в вашем коде 5 циклов, в моем 1. Я считаю нужно делать не так. Надо выделить ф-цию несущую основную смысловую нагрузку, дать ей хорошее имя, возможно добавить строку примечаний. Человек работающий с кодом разберется в ней (обычно достаточно имени/примечания, в тело вникать необязательно) а дальше просто будет ориентироваться на вызовы. То есть наоборот, подчеркнуть "сильную долю", а не всячески прятать ее в глубине функторов и лямбд. Еще раз ... Есть предложение спокойнее относиться к другим точкам зрения :)А давайте вы немного подумаете, и все таки попытаетесь понять что Название: Re: Итераторы Отправлено: alex312 от Апрель 23, 2013, 10:07 И что, это уже круто? Это не круто - это нормально, обыденно.Если std::transform, copy_if и.т.п.- это уже не цикл, а "лучше". А мне кажется это просто снобизм/фетишизм. Циклы в std::transform, copy_if писали люди поумнее меня, эти циклы стандартизированы, документированы, оттестированы миллионами, используются миллионами - и исходя из вышеперечисленного, да эти циклы лучше.Ваш код прямо-таки кричит "смотрите как много я знаю". Поэтому я пишу на C++, и не использую паскаль ;DЕсть предложение спокойнее относиться к другим точкам зрения :) Поддерживаю.Название: Re: Итераторы Отправлено: Igors от Апрель 23, 2013, 16:46 Циклы в std::transform, copy_if писали люди поумнее меня, "Слепая вера" (типа да примем без доказательств) конечно делает жизнь проще/практичнее - но в то же время IMO ущемляет программиста (кирпича-то нет, просто поверил) |