Здравствуйте, Kluev, Вы писали:
K>"Всегда будет" — это громкие, но пустые заявления. Вот к примеру простой жизненный пример: итерация пар соседних элементов в массиве для вычисления длинны полилинии
K>
K> double len = 0;
K> for (int i = 0; i < points.size() - 1; i++)
K> len += distance(point[i], point[i + 1]);
K> return len;
K>
K>Один универсальный цикл на все случаи жизни. Никакие дополнительные ветки не нужны. В std::С++ такое естественно работать не будет, std-программист либо наступит на грабли, либо будет вынужден погрузиться в микро-менеджмент и "перебрасывать слагаемые"
А теперь представим, что в процессе сопровождения и оптимизации у вас points из вектора превратился в простой список или список чанков. И у вас больше нет индекса, зато есть итераторы, которые позволяют вам итерироваться по новому контейнеру последовательно.
Ведь ваш цикл останется именно таким на все случаи жизни, не правда ли?
Ну или давайте посмотрим на знаковые индексы/размерности с другой стороны. Насколько они удобны не для последовательных итераций, а для произвольного доступа. Вот у нас есть вектор v размера N и мы по сложной формуле вычисляем позицию i в этом векторе. А перед обращением к v(i) нам нужно убедится, что i валидный. Что нам потребуется?
Потребуется написать два условия в проверке:
if(i >= 0 && i < N)
вместо всего одной для случая беззнаковых размеров и индексов.
Так вот, поскольку вы наверняка не поймете к чему я привожу эти примеры, мораль сей басни такова: ваш "малолетний дебилизм" состоит в том, что вы признаете единственно правильной только свою точку зрения. И в упор отказываетесь принимать тот факт, что ни у знаковых размерностей, ни у беззнаковых нет абсолютных преимуществ во всех сценариях использования. А раз так, то какой бы выбор не был сделан, всегда будут сценарии, когда сделанный выбор ведет либо к проблемам, либо к дополнительным накладным расходам.
Понимай вы это, вы бы не позволили себе высказывания в стиле юношеского максимализма, вроде: "Человек который имеет другую точку зрения, конечно имеет на нее полное право, но по сути является садомазохистом и не подходит для принятия общественно значимых решений по моральным качествам." Именно такой юношеский максимализм в ваших высказываниях и позволяет классифицировать вас как "малолетнего дебила".
K> double len = 0;
K> for (int i = 0; i < points.size() - 1; i++)
K> len += distance(point[i], point[i + 1]);
K> return len;
K>
K>Один универсальный цикл на все случаи жизни. Никакие дополнительные ветки не нужны.
Это какой-то тупой пример из области микрооптимизации непонятно чего на уровне ф-и, каноничный пример "микро-менеджмента", против которого ты здесь так ратуешь. Подобный "универсальный цикл на все случаи жизни" в вакууме нахрен никому не нужен, он не имеет собственной ценности. Т.е. где-то сверху это условие все равно будет, например на уровне ГУЯ, чтобы подобная операция была тупо задизейблена, в силу ее идиотизма. А наличие минимум двух точек — будет предусловием ф-и вычисления длины. Более того, в реальном мире, сам по себе инвариант класса полилинии будет состоять в том, что точек минимум две. Иначе ты просто даже создать экземпляр класса не сможешь.
Допускаю, что в каких-то хитрых случаях подобных цикл может иметь право на существование, но на то они и хитрые, зачем выдавать исключение за правило? А в каких-то других случаях — проще будет тупо задвоить точку. Например, в видео часто специально добавляют фиктивные строки слева/сверху блока, чтобы не вводить проверки во внутрь алгоритма обработки.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Kluev, Вы писали:
K>>"Всегда будет" — это громкие, но пустые заявления. Вот к примеру простой жизненный пример: итерация пар соседних элементов в массиве для вычисления длинны полилинии
K>>
K>> double len = 0;
K>> for (int i = 0; i < points.size() - 1; i++)
K>> len += distance(point[i], point[i + 1]);
K>> return len;
K>>
K>>Один универсальный цикл на все случаи жизни. Никакие дополнительные ветки не нужны. В std::С++ такое естественно работать не будет, std-программист либо наступит на грабли, либо будет вынужден погрузиться в микро-менеджмент и "перебрасывать слагаемые"
S>А теперь представим, что в процессе сопровождения и оптимизации у вас points из вектора превратился в простой список или список чанков. И у вас больше нет индекса, зато есть итераторы, которые позволяют вам итерироваться по новому контейнеру последовательно.
А давайте представим, что земля завтра налетит на небесную ось?
У классов на основе списков и на основе массивов разные сценарии использования, и если требуется то такие в программе живут параллельно, а не переделываются из одного в другой.
S>Ведь ваш цикл останется именно таким на все случаи жизни, не правда ли?
S>Ну или давайте посмотрим на знаковые индексы/размерности с другой стороны. Насколько они удобны не для последовательных итераций, а для произвольного доступа. Вот у нас есть вектор v размера N и мы по сложной формуле вычисляем позицию i в этом векторе. А перед обращением к v(i) нам нужно убедится, что i валидный. Что нам потребуется?
S>Потребуется написать два условия в проверке: S>
S>if(i >= 0 && i < N)
S>
S>вместо всего одной для случая беззнаковых размеров и индексов.
Это вам потребуется. А мне потребуется написать
if (vec.valid_index(i))
Я использую свои классы с рациональным набором операций
S>Так вот, поскольку вы наверняка не поймете к чему я привожу эти примеры,
Если вы себя официально позиционируете умнее своего собеседника, то вам надо видеть хотя-бы дальше своего носа. Но в вашем наивном примере, в якобы эффективном переходе от двух сравнений в if(i >= 0 && i < N) к одному в беззнак.арифметике, вы не видите леса за своим носом. Если вы "вычисляете" индекс в беззнаковой арифметике, то чтобы избежать переполнения ваши проверки просто переедут из кода обращения к массиву, в код вычисления индекса. Причем их число будет пропорционально размеру кода. В знаковой арифметике вы откупаетесь одним простым и эффективным if(i >= 0 && i < N)
S> мораль сей басни такова: ваш "малолетний дебилизм" состоит в том, что вы признаете единственно правильной только свою точку зрения. И в упор отказываетесь принимать тот факт, что ни у знаковых размерностей, ни у беззнаковых нет абсолютных преимуществ во всех сценариях использования. А раз так, то какой бы выбор не был сделан, всегда будут сценарии, когда сделанный выбор ведет либо к проблемам, либо к дополнительным накладным расходам.
Вы так говорите как будто каждый раз в коде делаете осознанный выбор в пользу знак. или беззнак. индексов. На самом деле кушаете то, что подают в стл. Мой осознанный выбор знаковая арифметика. Согласитесь что в такой ситуации ваши нравоучения и напыщенное сектанство не уместны. Вы — человек действующий шаблонно по указивке комитета, пытаетесь поучать человека действующего осознанно. Это просто смешно.
S>Понимай вы это, вы бы не позволили себе высказывания в стиле юношеского максимализма, вроде: "Человек который имеет другую точку зрения, конечно имеет на нее полное право, но по сути является садомазохистом и не подходит для принятия общественно значимых решений по моральным качествам." Именно такой юношеский максимализм в ваших высказываниях и позволяет классифицировать вас как "малолетнего дебила".
Здравствуйте, Patalog, Вы писали:
P>Здравствуйте, Kluev, Вы писали:
P>[]
K>>
K>> double len = 0;
K>> for (int i = 0; i < points.size() - 1; i++)
K>> len += distance(point[i], point[i + 1]);
K>> return len;
K>>
K>>Один универсальный цикл на все случаи жизни. Никакие дополнительные ветки не нужны.
P>Это какой-то тупой пример
Покажие острый
P> из области микрооптимизации непонятно чего на уровне ф-и, каноничный пример "микро-менеджмента", против которого ты здесь так ратуешь. Подобный "универсальный цикл на все случаи жизни" в вакууме нахрен никому не нужен, он не имеет собственной ценности.
Это банальный цикл для перебора массива парами соседних значений
P> Т.е. где-то сверху это условие все равно будет, например на уровне ГУЯ, чтобы подобная операция была тупо задизейблена, в силу ее идиотизма.
а если в программе нет ГУЯ?
P>А наличие минимум двух точек — будет предусловием ф-и вычисления длины.
А зачем нужно предусловие? Вы не доверяете математике?
P> Более того, в реальном мире, сам по себе инвариант класса полилинии будет состоять в том, что точек минимум две. Иначе ты просто даже создать экземпляр класса не сможешь.
пока вы говорите о мире выдуманном
P>Допускаю, что в каких-то хитрых случаях подобных цикл может иметь право на существование, но на то они и хитрые, зачем выдавать исключение за правило? А в каких-то других случаях — проще будет тупо задвоить точку. Например, в видео часто специально добавляют фиктивные строки слева/сверху блока, чтобы не вводить проверки во внутрь алгоритма обработки.
Этот цикл не тупой как вы сказали ранее и не хитрый, а вполне очевидный цикл для перебора пар элементов.
Здравствуйте, Patalog, Вы писали:
P>Более того, в реальном мире, сам по себе инвариант класса полилинии будет состоять в том, что точек минимум две. Иначе ты просто даже создать экземпляр класса не сможешь.
В реальном мире полилиния может состоять из одной точки. Например, траектория движения объекта:
1. объект обнаружен на первом кадре, его траектория-полилиния состоит из одной точки;
2. объект обнаружен на втором кадре, его траектория состоит из двух точек;
3. ...
Соответственно, вывод траектории таким вот способом вполне законен. Что тут такого?
Здравствуйте, Kluev, Вы писали:
K>А давайте представим, что земля завтра налетит на небесную ось?
Нет, не представим. Потому что это не имеет отношения к разработке софта.
K>У классов на основе списков и на основе массивов разные сценарии использования, и если требуется то такие в программе живут параллельно, а не переделываются из одного в другой.
Какая наивность. Вы вообще софт, который развивается больше одного месяца, когда-нибудь разрабатывали?
Требования к софту меняются. Профилирование заставляет менять структуры данных в программе. И т.д., и т.п.
K>Это вам потребуется. А мне потребуется написать
K>
K>if (vec.valid_index(i))
K>
K>Я использую свои классы с рациональным набором операций
И что же будет внутри valid_index? Неужели всего одна проверка?
K>Если вы себя официально позиционируете умнее своего собеседника, то вам надо видеть хотя-бы дальше своего носа.
Нет, не умнее. Вероятнее всего просто опытнее.
K>Но в вашем наивном примере, в якобы эффективном переходе от двух сравнений в if(i >= 0 && i < N) к одному в беззнак.арифметике, вы не видите леса за своим носом. Если вы "вычисляете" индекс в беззнаковой арифметике, то чтобы избежать переполнения ваши проверки просто переедут из кода обращения к массиву, в код вычисления индекса.
С чего бы? Это во-первых.
Во-вторых, программисты ошибаются. Поэтому даже в результате вычисления индекса с проверками по ходу вычисления, все равно может получится некорректный индекс. И последним бастионом выступит либо vector::at, либо его аналог.
В-третьих, даже если последовать вашему совету и делать проверки при вычислениях индекса, то там все равно будет две проверки вместо одной.
K>Причем их число будет пропорционально размеру кода.
Еще раз, с чего бы?
K>В знаковой арифметике вы откупаетесь одним простым и эффективным if(i >= 0 && i < N)
Т.е. в вашей вселенной if(i>=0 && i<N) прощее и эффективнее if(i < N)? O_o.
K>Вы — человек действующий шаблонно по указивке комитета, пытаетесь поучать человека действующего осознанно.
А с какого бодуна вы решили, что я действую по указивке комитета? Так уж получилось, что безннаковые числа для размерностей и индексов я начал применять еще до того, как комитет по стандартизации C++ начал работать.
Ну и, в отличии от вас, я не навязываю свою точку зрения. Были бы размерности/индексы знаковыми -- ок, работал бы со знаковыми или использовал бы беззнаковые, там где это нужно. Сейчас они беззнаковые и ОК, меня не парит то, что в чьих-то кодовых базах размерности/индексы знаковые.
Я не заставляю вас перейти от знаковых индексов к беззнаковым. И не пытаюсь доказать вам, что вы неправы в использовании знаковых индексов. И, уж тем более, не называю преверженцев знаковых размерностей/индексов моральными уродами, чье мнение не должно восприниматься всерьез.
Поэтому-то вы "малолетний дебил" (с), который считает, что его инфантильные желания должны быть превыше всего, а его мнение безусловно является самым правильным.
S>Требования к софту меняются. Профилирование заставляет менять структуры данных в программе. И т.д., и т.п.
Не припомню случая когда приходилось бы менять вектор на список и наоборот. Слишком разные сценарии использования. А проектировать софт с учетом возможного столкновения с небесной осью я смысла не вижу.
K>>Но в вашем наивном примере, в якобы эффективном переходе от двух сравнений в if(i >= 0 && i < N) к одному в беззнак.арифметике, вы не видите леса за своим носом. Если вы "вычисляете" индекс в беззнаковой арифметике, то чтобы избежать переполнения ваши проверки просто переедут из кода обращения к массиву, в код вычисления индекса.
S>С чего бы? Это во-первых.
K>>В знаковой арифметике вы откупаетесь одним простым и эффективным if(i >= 0 && i < N)
S>Т.е. в вашей вселенной if(i>=0 && i<N) прощее и эффективнее if(i < N)? O_o.
Имею смелость утверждать. Т.к. реальном мире любая операция минус в беззнаковой арифметике небезопасна и потребует проверки, любая смешанная арифметика небезопасна и потребует проверки. Написание проверок требует дополнительных мысленных усилий и ухудшает читаемость и качество кода. А когда вы эту писанину еще на всякий случай подстрахуете vector::at можете окончательно попрощаться с эффективностью. Отдельно взятый оператор if(i < N) будет эффективней отдельно взятого if(i>=0 && i<N) вот только за ним стоит такой лес граблей, ненужных проверок и ненужных усилий которые сводят на нет всю его мнимую эффективность.
K>>Вы — человек действующий шаблонно по указивке комитета, пытаетесь поучать человека действующего осознанно.
S>А с какого бодуна вы решили, что я действую по указивке комитета? Так уж получилось, что безннаковые числа для размерностей и индексов я начал применять еще до того, как комитет по стандартизации C++ начал работать.
Значит вы с комитетом "нашли" друг друга.
S>Ну и, в отличии от вас, я не навязываю свою точку зрения. Были бы размерности/индексы знаковыми -- ок, работал бы со знаковыми или использовал бы беззнаковые, там где это нужно. Сейчас они беззнаковые и ОК, меня не парит то, что в чьих-то кодовых базах размерности/индексы знаковые.
S>Я не заставляю вас перейти от знаковых индексов к беззнаковым. И не пытаюсь доказать вам, что вы неправы в использовании знаковых индексов. И, уж тем более, не называю преверженцев знаковых размерностей/индексов моральными уродами, чье мнение не должно восприниматься всерьез.
Я не навязываю, а утверждаю очевидные вещи, что в общей практике знаковые индексы имеют больше преимуществ. Чему и следуют большинство языков программирования.
S>Поэтому-то вы "малолетний дебил" (с), который считает, что его инфантильные желания должны быть превыше всего, а его мнение безусловно является самым правильным.
Правильность моего мнения доказывает большинство языков программирования на нашей планете. А ваши оскорбления доказывают лишь только ваш уровень культуры.
Здравствуйте, Kluev, Вы писали:
S>>Требования к софту меняются. Профилирование заставляет менять структуры данных в программе. И т.д., и т.п.
K>Не припомню случая когда приходилось бы менять вектор на список и наоборот. Слишком разные сценарии использования. А проектировать софт с учетом возможного столкновения с небесной осью я смысла не вижу.
Т.е. если вы не видели, значит этого нет. Понятно.
А такие случаи бывают. Более того, для каких-то сценариев приходится менять тип контейнера прямо в run-time, скажем, с vector на map или set.
А теперь возвращается к вашему "циклу на все случаи жизни". Он таковым не является. А вот если бы вы написали его на итераторах, то он бы при переходе от vector к list или deque или даже к set не поменялся бы. При этом вам было бы фиолетово, что скрывается за итератором -- знаковые индексы или беззнаковые.
K>>>В знаковой арифметике вы откупаетесь одним простым и эффективным if(i >= 0 && i < N)
S>>Т.е. в вашей вселенной if(i>=0 && i<N) прощее и эффективнее if(i < N)? O_o.
K>Имею смелость утверждать.
Т.е. аргументация "Kluev сказал"? Ну тогда сразу в /dev/null вместе с утверждениями "Человек который имеет другую точку зрения, конечно имеет на нее полное право, но по сути является садомазохистом и не подходит для принятия общественно значимых решений по моральным качествам."
K>Т.к. реальном мире любая операция минус в беззнаковой арифметике небезопасна и потребует проверки, любая смешанная арифметика небезопасна и потребует проверки. Написание проверок требует дополнительных мысленных усилий и ухудшает читаемость и качество кода.
Ох ё, детский сад, младшая ясельная группа. А знаковые у вас никогда не переполнялись? Или может вы думаете, что переполнение знаковых -- это ничего страшного, и даже не UB?
K>Отдельно взятый оператор if(i < N) будет эффективней отдельно взятого if(i>=0 && i<N) вот только за ним стоит такой лес граблей, ненужных проверок и ненужных усилий которые сводят на нет всю его мнимую эффективность.
Отучаемся говорить за всех (c).
K>Я не навязываю, а утверждаю очевидные вещи,
Повторюсь: поэтому-то вы "малолетний дебил" (с), который считает, что его инфантильные желания должны быть превыше всего, а его мнение безусловно является самым правильным.
K>Правильность моего мнения доказывает большинство языков программирования на нашей планете.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Kluev, Вы писали:
S>>>Требования к софту меняются. Профилирование заставляет менять структуры данных в программе. И т.д., и т.п.
K>>Не припомню случая когда приходилось бы менять вектор на список и наоборот. Слишком разные сценарии использования. А проектировать софт с учетом возможного столкновения с небесной осью я смысла не вижу.
S>Т.е. если вы не видели, значит этого нет. Понятно. S>А такие случаи бывают. Более того, для каких-то сценариев приходится менять тип контейнера прямо в run-time, скажем, с vector на map или set.
С++ такие пируэты не поддерживает
S>А теперь возвращается к вашему "циклу на все случаи жизни". Он таковым не является. А вот если бы вы написали его на итераторах, то он бы при переходе от vector к list или deque или даже к set не поменялся бы. При этом вам было бы фиолетово, что скрывается за итератором -- знаковые индексы или беззнаковые.
Вы предлагаете один дефект stl победить с помощью другого кривого stl-костыля. Но если бы вместо оскорблений вы потрудились посмотреть дальше своего носа, то поняли бы, что за вашим предложением скрываются серьезные грабли, например при смене контейнера с list на vector итератор может стать невалидным (при вставке элемента в теле цикла). И в если случае с индексами вы бы получили ошибку компиляции и смогли бы провести ревизию кода, то с итераторами вы получите ошибку времени выполнения со всеми вытекающими последствиями. Т.е ваши методы гладки только на бумаге, а в реальной жизни гладкостью там и не пахнет. Собственно вся stl и есть бумажная концепция, малопригодная для программирования, для тех кто слаще морковки ничего в жизни не видел.
K>>>>В знаковой арифметике вы откупаетесь одним простым и эффективным if(i >= 0 && i < N)
S>>>Т.е. в вашей вселенной if(i>=0 && i<N) прощее и эффективнее if(i < N)? O_o.
K>>Имею смелость утверждать.
S>Т.е. аргументация "Kluev сказал"? Ну тогда сразу в /dev/null вместе с утверждениями "Человек который имеет другую точку зрения, конечно имеет на нее полное право, но по сути является садомазохистом и не подходит для принятия общественно значимых решений по моральным качествам."
Конечно, тех кто продвигает беззнаковые индексы в качестве общего решения гнать надо из комитетов. Вред от таких людей колоссальный, пусть в своих частных задачах хоть в даблах индексируются.
K>>Т.к. реальном мире любая операция минус в беззнаковой арифметике небезопасна и потребует проверки, любая смешанная арифметика небезопасна и потребует проверки. Написание проверок требует дополнительных мысленных усилий и ухудшает читаемость и качество кода.
S>Ох ё, детский сад, младшая ясельная группа. А знаковые у вас никогда не переполнялись? Или может вы думаете, что переполнение знаковых -- это ничего страшного, и даже не UB?
Знаковые на пустом месте не переполняются.
S>Повторюсь: поэтому-то вы "малолетний дебил" (с), который считает, что его инфантильные желания должны быть превыше всего, а его мнение безусловно является самым правильным.
K>>Правильность моего мнения доказывает большинство языков программирования на нашей планете.
S>Большинство языков программирования вообще не ставят во главу угла эффективность (или даже плюют на какие-то платформы). А вот в языках, которые на эффективность заточены, размерности и индексы беззнаковые: C, C++, Rust
Да не смешите сказками про эффективность, особенно сишные строки-то очень эффективны. С вообще был сделан из говна и палок. Думали бы об эффективности такую дрянь как препроцессор вообще бы не потащили в язык. Эффективность С++ это тоже анекдот. Ну а руст это очередной мертворожденный язык. Т.к время каркозябро-ориентированных языков требующих постоянного микроменеджемнта уже прошло.
хъ
K>Это банальный цикл для перебора массива парами соседних значений
Для перебора пар не нужен знаковый размер.
P>> Т.е. где-то сверху это условие все равно будет, например на уровне ГУЯ, чтобы подобная операция была тупо задизейблена, в силу ее идиотизма. K>а если в программе нет ГУЯ?
Значит будет что-то другое.
P>>А наличие минимум двух точек — будет предусловием ф-и вычисления длины.
K>А зачем нужно предусловие? Вы не доверяете математике?
хъ
N>В реальном мире полилиния может состоять из одной точки. Например, траектория движения объекта: N>1. объект обнаружен на первом кадре, его траектория-полилиния состоит из одной точки;
Вы правы, в реальном мире наверняка бывают программы, которые падают потому-что длина "полилинии из одной точки" рана 0. В этом мире чего только не бывает.
Здравствуйте, Kluev
K>С++ такие пируэты не поддерживает
K>например при смене контейнера с list на vector итератор может стать невалидным (при вставке элемента в теле цикла). И в если случае с индексами вы бы получили ошибку компиляции и смогли бы провести ревизию кода, то с итераторами вы получите ошибку времени выполнения со всеми вытекающими последствиями. Т.е ваши методы гладки только на бумаге, а в реальной жизни гладкостью там и не пахнет. Собственно вся stl и есть бумажная концепция, малопригодная для программирования, для тех кто слаще морковки ничего в жизни не видел.
K>Знаковые на пустом месте не переполняются.
K>Ну а руст это очередной мертворожденный язык. Т.к время каркозябро-ориентированных языков требующих постоянного микроменеджемнта уже прошло.
Простите, но это уже не "малолетний дебилизм", это чистой воды идиотия.
Здравствуйте, Patalog, Вы писали:
P>Вы правы, в реальном мире наверняка бывают программы, которые падают потому-что длина "полилинии из одной точки" рана 0. В этом мире чего только не бывает.
Длина полилинии может быть равна 0 и тогда, когда она состоит из множества точек.
Например, при детекции объект неподвижен и все точки его траектории одинаковые.
Или мы ищем проекцию полилинии с ненулевой длиной на плоскость, а уже на плоскости эта проекция (тоже полилиния) отобразится в точку, но также будет ненулевой длины.
Что ты так прицепился к этому циклу — я не понимаю. Тебя смущает приставка "поли"? Так она не накладывает ограничение снизу, бывают и полиномы нулевой степени.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Kluev
K>>С++ такие пируэты не поддерживает
K>>например при смене контейнера с list на vector итератор может стать невалидным (при вставке элемента в теле цикла). И в если случае с индексами вы бы получили ошибку компиляции и смогли бы провести ревизию кода, то с итераторами вы получите ошибку времени выполнения со всеми вытекающими последствиями. Т.е ваши методы гладки только на бумаге, а в реальной жизни гладкостью там и не пахнет. Собственно вся stl и есть бумажная концепция, малопригодная для программирования, для тех кто слаще морковки ничего в жизни не видел.
K>>Знаковые на пустом месте не переполняются.
K>>Ну а руст это очередной мертворожденный язык. Т.к время каркозябро-ориентированных языков требующих постоянного микроменеджемнта уже прошло.
S>Простите, но это уже не "малолетний дебилизм", это чистой воды идиотия.
Вам пишут очевидные вещи, вы называете их идиотией и сопровождаете оскорблениями. Вы адекватный вообще? Наверное стоит прекратить с вами общение.
Здравствуйте, Kluev, Вы писали:
K>Вам пишут очевидные вещи, вы называете их идиотией и сопровождаете оскорблениями. Вы адекватный вообще? Наверное стоит прекратить с вами общение.
Вам дали адекватную оценку ваших заблуждений и очевидного незнания предмета разговора. Но вам проще обвинить собеседника в неадекватности, чем попробовать прокачать собственные знания и кругозор.
По каждому из процитированных мной выше ваших идиотских высказываний можно отдельную статью с кучей примеров написать. Чего, по вполне очевидным причинам, делать не буду.
[]
N>Длина полилинии может быть равна 0 и тогда, когда она состоит из множества точек.
Допустим. Но в этом случае у нас нет полилинии из одной точки или тем более из пустого множества.
N>Например, при детекции объект неподвижен и все точки его траектории одинаковые.
У вас какое-то свое понимание траектории, ибо по определению описывает движение объекта. Но не суть, не будем спорить о терминах.
N>Или мы ищем проекцию полилинии с ненулевой длиной на плоскость, а уже на плоскости эта проекция (тоже полилиния) отобразится в точку, но также будет ненулевой длины. N>Что ты так прицепился к этому циклу — я не понимаю.
Я прицепился? По моему это вы с Клюевым предлагаете этот цикл как икону стиля, дескать как хорошо — не нужны никакие доп. проверки, size() — 1 и ага, а вот с беззнаковыми дескать доп. проверки нужны. И хотя было уже показано, что это не так, т.е. если очень захотеть, то и с беззнаковыми можно обойтись, суть не в этом, позвольте мне еще раз повторить —
В алгоритме, в котором нужно "перебрать все элементы кроме первого и последнего" всегда будет отдельная ветка логики для пустого массива (скорее даже size() < 3), иначе он будет ломаться пусть не на этом конкретном цикле, а где-то еще. А это "всегда будет корректно работать" — тупое заметание мусора под коврик.
N>Тебя смущает приставка "поли"? Так она не накладывает ограничение снизу, бывают и полиномы нулевой степени.
Здравствуйте, Patalog, Вы писали:
P>У вас какое-то свое понимание траектории, ибо по определению описывает движение объекта. Но не суть, не будем спорить о терминах.
Нормальное понимание. Если говорить о видеонаблюдении, но мы наблюдаем проекцию траектории движения объекта на матрице видеокамеры. Движется объект или нет, но его траектория (результаты измерения положения на каждом кадре) может выродаться в одну точку и тогда, когда объект двигается в пространстве, и тогда, когда нет.
P>Я прицепился? По моему это вы с Клюевым предлагаете этот цикл как икону стиля, дескать как хорошо — не нужны никакие доп. проверки, size() — 1 и ага, а вот с беззнаковыми дескать доп. проверки нужны. И хотя было уже показано, что это не так, т.е. если очень захотеть, то и с беззнаковыми можно обойтись, суть не в этом, позвольте мне еще раз повторить - P>
P>В алгоритме, в котором нужно "перебрать все элементы кроме первого и последнего" всегда будет отдельная ветка логики для пустого массива (скорее даже size() < 3), иначе он будет ломаться пусть не на этом конкретном цикле, а где-то еще. А это "всегда будет корректно работать" — тупое заметание мусора под коврик.
Я не считаю этот цикл иконой стиля, но считаю его вполне корректным и понятным, если мы не работаем с беззнаковыми типами. Это не заметание мусора под коврик, в реальности есть случаи, когда надо рисовать на экране линию, которая состоит из одной точки. Лично у меня это было минимум в 3 случаях:
1. При первом обнаружении объекта его траектория состояит из 1 точки и вывод её на экран производился ровно описываемым циклом. Никаких других условий, всё прозрачно и понятно.
2. Когда объект движется, но траектори его оптимизируется и из неё выкидываются точки, чьи координаты во времени не меняются. Что-то типа RLE сжатия — в этом случае траектория может выродиться в одну точку, хотя изначально она имела длину и состояла из большого числа точек.
3. Когда объект трекается в 3D координатах в метрах относительно системы координат в пространстве на поверхности геоида, а потом его траектория проецируется на 2D координатную систему видео в пикселях. Проекция протяжённой в пространстве линии может схлопнуться до одной точки — например, далёкий маленький объект.
И я искренне не понимаю что такого в предложенном цикле: понятен и удобен.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Kluev, Вы писали:
K>>Вам пишут очевидные вещи, вы называете их идиотией и сопровождаете оскорблениями. Вы адекватный вообще? Наверное стоит прекратить с вами общение.
S>Вам дали адекватную оценку ваших заблуждений и очевидного незнания предмета разговора. Но вам проще обвинить собеседника в неадекватности, чем попробовать прокачать собственные знания и кругозор.
Перечитайте хотя бы собственные сообщения. Где там адекват? Хамство и надуманные, поверхностные примеры. Особенно примечательно ваше предложение писать все в итераторах ради "гибкости", а на самом деле прыгать по граблям перенося ошибки времени компиляции в рантайм.
S>По каждому из процитированных мной выше ваших идиотских высказываний можно отдельную статью с кучей примеров написать. Чего, по вполне очевидным причинам, делать не буду.
Да вы хотя-бы один пример адекватный привели, вместо пусто и сквернословия.
Дальнейший спор на тему что лучше — объект с четко прописанным поведением и инвариантами vs что-то, что может быть точкой, полилинией, проекцией оной на еще что-то, %u-name-it% — считаю бесперспективным.
N>И я искренне не понимаю что такого в предложенном цикле: понятен и удобен.
То, что могут быть случаи когда подобные (в т.ч. и продемонстрированный rg45) могут быть уместны — никто не спорит. Даже пресловутый goto в нек. случаях быть вполне к месту. Но я искренне не понимаю, как подобные примеры могут служить аргументом за использование знаковых целых для индексации и обозначения кол-ва элементов в контейнере.
Здравствуйте, Kluev, Вы писали:
K>Перечитайте хотя бы собственные сообщения. Где там адекват?
Везде. В отличии от. Поскольку:
Можете возразить, что длинно, но до auto stl-юзеры писали километровые std::map<..........., ...........>::const_iterator и не потели. Что касается литералов, то это фантастически бесполезная лабуда. Кто вообще их просил делать это?
...
Если вы не в курсе от раннего stl-мазохизма в продакшене активно отказывались и пересаживались на собственные разработки.
...
на фоне вот этих вопиющих дыр полный бред тратить усилия на такие бесполезные параши как литералы.
...
Самой важной причиной является то, что stl криво спроектированная библиотека. В ней плохо практически все.
...
Эти литералы сделаны в угоду нескольким фрикам, которым не терпелось добавить в stl константы типа в минуте 60 секунд.
просто таки образчики адекватности. И это ведь далеко не все, что вы решили выплеснуть на читателей ваших бредней.
K>Особенно примечательно ваше предложение писать все в итераторах ради "гибкости", а на самом деле прыгать по граблям перенося ошибки времени компиляции в рантайм.
Вы в очередной раз расписываетесь в незнании материала о котором пытаетесь рассуждать.
K>Да вы хотя-бы один пример адекватный привели, вместо пусто и сквернословия.
У вас неоднократно просили пример проблем с отсутствием forward declaration для вложенных классов, но вы так и не смогли (напомню, что ни на один наводящий вопрос по поводу вашего storage и storage::blob-а вы не ответили). А теперь просите, чтобы вам привели пример?
