Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Kluev, Вы писали:
K>>Перечитайте хотя бы собственные сообщения. Где там адекват?
S>Везде. В отличии от. Поскольку:
Смешно слышать такое от человека, который занимается отрицанием реальности. Напомню, что наше общение началось с отрицания вами проблемы опережающего описания вложенных классов.
Так ведь не сломано ничего. Исправлять незачем.
S>
Можете возразить, что длинно, но до auto stl-юзеры писали километровые std::map<..........., ...........>::const_iterator и не потели. Что касается литералов, то это фантастически бесполезная лабуда. Кто вообще их просил делать это?
S>...
S>Если вы не в курсе от раннего stl-мазохизма в продакшене активно отказывались и пересаживались на собственные разработки.
S>...
S>на фоне вот этих вопиющих дыр полный бред тратить усилия на такие бесполезные параши как литералы.
S>...
S>Самой важной причиной является то, что stl криво спроектированная библиотека. В ней плохо практически все.
S>...
S>Эти литералы сделаны в угоду нескольким фрикам, которым не терпелось добавить в stl константы типа в минуте 60 секунд.
S>просто таки образчики адекватности. И это ведь далеко не все, что вы решили выплеснуть на читателей ваших бредней.
Подписываюсь под каждым словом. Полнейший неадекват тащить в язык сомнительные фичи, превращающие его в помойку, в то время как в языке сотни вопиющих неисправленных проблем.
K>>Особенно примечательно ваше предложение писать все в итераторах ради "гибкости", а на самом деле прыгать по граблям перенося ошибки времени компиляции в рантайм.
S>Вы в очередной раз расписываетесь в незнании материала о котором пытаетесь рассуждать.
Вы в очередной раз неспособны заглянуть дальше своего носа. Все-таки придется пояснить
std::list<int> lst; // std::vector<int> lst;
lst.push_back(1);
lst.push_back(2);
lst.push_back(3);
lst.push_back(4);
for (auto it = lst.begin(); it != lst.end(); it++)
{
if (*it % 2)
lst.insert(it, *it);
}
Вот этот код при замене list на vector будет прекрасно компилироваться, но порождать ошибку времен выполнения. Т.е. сценарий когда вы меняете тип контейнера и все "работает" является просто пустым обещанием. В действительности итераторы только ухудшают читаемость и качество кода и создают потенциальные проблемы времени выполнения. Используя родные средства итерирования контейнера (индексы для векторов и указатели для списков) программист вынужден при смене контейнера сделать ревизию кода и исправить потенциальные проблемы.
K>>Да вы хотя-бы один пример адекватный привели, вместо пусто и сквернословия.
S>У вас неоднократно просили пример проблем с отсутствием forward declaration для вложенных классов, но вы так и не смогли (напомню, что ни на один наводящий вопрос по поводу вашего storage и storage::blob-а вы не ответили). А теперь просите, чтобы вам привели пример?
пример со storage и storage::blob был исчерпывающим, просто вы решили прикинутся шлангом и продолжить отрицание реальности.
S>Ну, OK. Пример чего вы бы хотели увидеть?
Ну вы же там грозились, что можно на мои аргументы статью опровержений написать. Вот и опровергните хотя бы один.
Здравствуйте, Kluev, Вы писали:
K>Смешно слышать такое от человека, который занимается отрицанием реальности. Напомню, что наше общение началось с отрицания вами проблемы опережающего описания вложенных классов.
K>
Так ведь не сломано ничего. Исправлять незачем.
Так вы и не показали проблемы. Раз проблемы нет, то и исправлять нечего.
K>Подписываюсь под каждым словом. Полнейший неадекват тащить в язык сомнительные фичи, превращающие его в помойку, в то время как в языке сотни вопиющих неисправленных проблем.
Не вопрос, раз "малолетний дебил", значит "малолетний дебил", особенно если он сами на этом настаивает.
K>Вот этот код при замене list на vector будет прекрасно компилироваться, но порождать ошибку времен выполнения. Т.е. сценарий когда вы меняете тип контейнера и все "работает" является просто пустым обещанием. В действительности итераторы только ухудшают читаемость и качество кода и создают потенциальные проблемы времени выполнения. Используя родные средства итерирования контейнера (индексы для векторов и указатели для списков) программист вынужден при смене контейнера сделать ревизию кода и исправить потенциальные проблемы.
Это все хорошо, но вот только не имеет отношения к вашему утверждению про "Один универсальный цикл на все случаи жизни."
Если вы забыли, то я вам даже напомню что это за цикл:
double len = 0;
for (int i = 0; i < points.size() - 1; i++)
len += distance(point[i], point[i + 1]);
return len;
Так вот, если бы вы этот цикл написали на итераторах, то было бы без разницы, итерируетесь ли вы по вектору, простому списку, списку чанков, множеству или еще чему-нибудь.
Но поскольку против этого вы, очевидно, ничего возразить не можете, то вы на ходу придумываете другой пример, уже с модификацией контейнера по ходу итерации. Да еще и столь откровенно расписываетесь в незнании STL. Давайте я вам покажу, как этот пример должен был бы выглядеть на STL-ных контейнерах и итераторах (цинк):
std::list/*std::vector*/<int> lst{ 1, 2, 3, 4 };
for(auto it = lst.begin(); it != lst.end(); ++it)
{
if(*it % 2)
{
it = ++lst.insert(it, *it);
}
}
Ну позвольте продемонстрировать вам другие грабли с модификацией вектора, которые будут присутствовать вне зависимости от того, идете вы по вектору посредством итераторов или индексов:
S>>У вас неоднократно просили пример проблем с отсутствием forward declaration для вложенных классов, но вы так и не смогли (напомню, что ни на один наводящий вопрос по поводу вашего storage и storage::blob-а вы не ответили). А теперь просите, чтобы вам привели пример?
K>пример со storage и storage::blob был исчерпывающим, просто вы решили прикинутся шлангом и продолжить отрицание реальности.
Нет. Вам были заданы вопросы, на которые вы отвечать отказались, т.е. слились. Посему незачет. Наличие проблемы вы не показали.
Если вы вдруг захотите ответить, то вот вопросы на которые хотелось бы получить ответы:
Простите, а это пример чего? Почему я должен думать, что все эти описания равноценны? Если вы считаете, что второй вариант является аналогом первого, то вы что-то делаете явно не так и в первом варианте нет смысла вкладывать blob в storage.
и где здесь можно увидеть использование хоть storage, хоть storage::blob вот в этих примерах:
Поскольку здесь использования нет.
S>>Ну, OK. Пример чего вы бы хотели увидеть?
K>Ну вы же там грозились, что можно на мои аргументы статью опровержений написать. Вот и опровергните хотя бы один.
Так ведь ваше незнание материала уже было показано чуть выше. Нужны еще какие-то примеры?
Здравствуйте, Kluev, Вы писали:
BFE>>Переполнение знаковых индексов — это ещё хуже. K>Что значит хуже?
Это значит, что результат переполнения может быть разный в зависимости от компилятора и платформы.
K>В обоих случаях переполнение приведет к ошибочному ходу выполнения программы.
Нет, конечно. На переполнение беззнаковых можно закладываться, а вот на переполнение знаковых — нет.
K>Не будете же вы утверждать что при беззнаковом переполнении ошибочное выполнение будет "менее ошибочным".
Что такое "менее ошибочным"?
K>Но случаев когда переполнение возможно в беззнаковой арифметике однозначно больше.
Конечно случаев больше и поэтому с беззнаковыми переменными программы лучше отлажены, так как выявление ошибки происходит практически сразу, а не через 2147483647 операций.
Здравствуйте, Kluev, Вы писали:
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-программист либо наступит на грабли, либо будет вынужден погрузиться в микро-менеджмент и "перебрасывать слагаемые"
Здравствуйте, Kluev, Вы писали:
K>В действительности итераторы только ухудшают читаемость и качество кода и создают потенциальные проблемы времени выполнения. Используя родные средства итерирования контейнера (индексы для векторов и указатели для списков) программист вынужден при смене контейнера сделать ревизию кода и исправить потенциальные проблемы.
Итераторы — это идеальная низкоуровневая абстракция, которая позволяет работать с любыми коллекциями без потери эффективности (в отличие например IEnumerable и т.п.). Однако т.к. это низкий уровень, то он должен применяться скорее при написание библиотек и т.п., а в повседневной работе программисту должны быть доступны более удобные абстракции, повыше уровнем. Благо в C++ они теперь есть — это std::ranges. И в таком виде мы получаем краткий, удобный и эффективный код. Что же касается древних итераций по индексу в стиле C... Ну как бы иногда и такое бывает надо (личное мне оно особенно часто в графике встречалось и в матрицах, причём там уже актуальна оптимизация под SIMD и всё такое), но у меня такое ощущение, что некоторые программисты ставят их просто везде от незнания и неумения.
Здравствуйте, alex_public, Вы писали:
_>Что же касается древних итераций по индексу в стиле C... Ну как бы иногда и такое бывает надо (личное мне оно особенно часто в графике встречалось и в матрицах, причём там уже актуальна оптимизация под SIMD и всё такое), но у меня такое ощущение, что некоторые программисты ставят их просто везде от незнания и неумения.
1. А как же одновременная итерация по нескольким массивам? У меня есть такой код, который только на индексах выглядит нормально.
2. Случай итерации по модулю индекса. При рисовании замкнутых фигур или циклическому буферу. Тут есть что-то лучше индекса?
3. Иногда индекс сам по себе несёт семантику, а не просто указывает на позицию элемента в контейнере.
Здравствуйте, Nuzhny, Вы писали:
_>>Что же касается древних итераций по индексу в стиле C... Ну как бы иногда и такое бывает надо (личное мне оно особенно часто в графике встречалось и в матрицах, причём там уже актуальна оптимизация под SIMD и всё такое), но у меня такое ощущение, что некоторые программисты ставят их просто везде от незнания и неумения.
N>1. А как же одновременная итерация по нескольким массивам? У меня есть такой код, который только на индексах выглядит нормально. N>2. Случай итерации по модулю индекса. При рисовании замкнутых фигур или циклическому буферу. Тут есть что-то лучше индекса? N>3. Иногда индекс сам по себе несёт семантику, а не просто указывает на позицию элемента в контейнере.
Так я же вроде ясно написал, что иногда такое нужное (и мне в том числе, даже примеры привёл). Но думаю что вполне очевидно, что эти применения являются явным меньшинством по отношению к общему числу применений контейнеров в программе.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Kluev, Вы писали:
K>>Смешно слышать такое от человека, который занимается отрицанием реальности. Напомню, что наше общение началось с отрицания вами проблемы опережающего описания вложенных классов.
K>>
Так ведь не сломано ничего. Исправлять незачем.
S>Так вы и не показали проблемы. Раз проблемы нет, то и исправлять нечего.
Эту проблему даже в комитете увидели. Спустя всего 20 лет. Ссылку уже постили http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0289r0.pdf
Чтобы вам проблему увидеть сколько лет потребуется?
K>>Подписываюсь под каждым словом. Полнейший неадекват тащить в язык сомнительные фичи, превращающие его в помойку, в то время как в языке сотни вопиющих неисправленных проблем.
S>Не вопрос, раз "малолетний дебил", значит "малолетний дебил", особенно если он сами на этом настаивает.
Вам видимо очень хочется послушать встречные оскорбления. Помню какое-то время назад здесь за оскорбления активно банили. Жаль сейчас отошли от этой славной традиции.
K>>Вот этот код при замене list на vector будет прекрасно компилироваться, но порождать ошибку времен выполнения. Т.е. сценарий когда вы меняете тип контейнера и все "работает" является просто пустым обещанием. В действительности итераторы только ухудшают читаемость и качество кода и создают потенциальные проблемы времени выполнения. Используя родные средства итерирования контейнера (индексы для векторов и указатели для списков) программист вынужден при смене контейнера сделать ревизию кода и исправить потенциальные проблемы.
S>Это все хорошо, но вот только не имеет отношения к вашему утверждению про "Один универсальный цикл на все случаи жизни." S>Если вы забыли, то я вам даже напомню что это за цикл: S>
double len = 0;
S>for (int i = 0; i < points.size() - 1; i++)
S> len += distance(point[i], point[i + 1]);
S>return len;
S>
S>Так вот, если бы вы этот цикл написали на итераторах, то было бы без разницы, итерируетесь ли вы по вектору, простому списку, списку чанков, множеству или еще чему-нибудь.
Ну хорошо. Этот цикл вы предлагаете писать на итераторах. А другие циклы в программе на чем писать? Вам не кажется что программа в таком случае будет слишком пестрой? Когда мы в одном случае удачно применяем неудачные std концепции, а в другом случае уклоняемся от их потенциальных граблей. Качество кода при таком подходе только ухудшается. Правильно просто не использовать кривые решения. Те кто может себе это позволить так и делают. Вот насколько я знаю в ФБ своя С++ библиотека. Или по вашему там тоже одни малолетние дебилы неосиляторы?
S>Но поскольку против этого вы, очевидно, ничего возразить не можете, то вы на ходу придумываете другой пример, уже с модификацией контейнера по ходу итерации. Да еще и столь откровенно расписываетесь в незнании STL. Давайте я вам покажу, как этот пример должен был бы выглядеть на STL-ных контейнерах и итераторах (цинк): S>
А то что циклы в программе могут быть разными это для вас открытие? Впрочем все что нужно я уже написал в абзаце выше.
S>Ну позвольте продемонстрировать вам другие грабли с модификацией вектора, которые будут присутствовать вне зависимости от того, идете вы по вектору посредством итераторов или индексов: S>
Для вашего примера нужно просто взять знаковый индекс int found_item = -1; и после цикла проверить if (found_item >= 0)
Смотрите как легко становится жить если тип индекса был выбран правильно.
И кстати в этом примере использовать свои любимые итераторы вы не сможете, т.к. итератор тоже будет невалидным.
Вам все равно придется использовать индекс элемента, а т.к. в std он беззнаковый еще и заворачивать его в std::optional
Вот так с кривым stl вы автоматически получаете кривизну на пустом месте.
S>>>У вас неоднократно просили пример проблем с отсутствием forward declaration для вложенных классов, но вы так и не смогли (напомню, что ни на один наводящий вопрос по поводу вашего storage и storage::blob-а вы не ответили). А теперь просите, чтобы вам привели пример?
K>>пример со storage и storage::blob был исчерпывающим, просто вы решили прикинутся шлангом и продолжить отрицание реальности.
S>Нет. Вам были заданы вопросы, на которые вы отвечать отказались, т.е. слились. Посему незачет. Наличие проблемы вы не показали.
Почему-то все участники обсуждения все поняли, в отличии от вас. Так что это ваши проблемы.
S>Если вы вдруг захотите ответить, то вот вопросы на которые хотелось бы получить ответы: S>
Простите, а это пример чего? Почему я должен думать, что все эти описания равноценны? Если вы считаете, что второй вариант является аналогом первого, то вы что-то делаете явно не так и в первом варианте нет смысла вкладывать blob в storage.
S>и где здесь можно увидеть использование хоть storage, хоть storage::blob вот в этих примерах: S>
А это что по вашему? void foo(Storage::Blob *blob); здесь черным по белому используется опережающее описание. Вы извините в шары долбитесь?
S>>>Ну, OK. Пример чего вы бы хотели увидеть?
K>>Ну вы же там грозились, что можно на мои аргументы статью опровержений написать. Вот и опровергните хотя бы один.
S>Так ведь ваше незнание материала уже было показано чуть выше. Нужны еще какие-то примеры?
А вами продемонстрировано непонимание материала. Что гораздо хуже незнания. Что же касается незнания stl то мне нет и нужды знать то, что я не использую и не планирую использовать.
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, Kluev, Вы писали:
BFE>>>Переполнение знаковых индексов — это ещё хуже. K>>Что значит хуже? BFE>Это значит, что результат переполнения может быть разный в зависимости от компилятора и платформы.
K>>В обоих случаях переполнение приведет к ошибочному ходу выполнения программы. BFE>Нет, конечно. На переполнение беззнаковых можно закладываться, а вот на переполнение знаковых — нет.
С переполнением беззнаковых сложнее работать, т.к. при переполнении у вас будет валидный индекс 0
а со знаковыми вы уйдете в отрицательную область невалидных индексов.
K>>Не будете же вы утверждать что при беззнаковом переполнении ошибочное выполнение будет "менее ошибочным". BFE>Что такое "менее ошибочным"?
K>>Но случаев когда переполнение возможно в беззнаковой арифметике однозначно больше. BFE>Конечно случаев больше и поэтому с беззнаковыми переменными программы лучше отлажены, так как выявление ошибки происходит практически сразу, а не через 2147483647 операций.
а через 4294967296 операций с беззнаковыми что происходит?
Увидели и сказали "да и х с ним". Что как бы говорит, что актуальность этой проблемы, мягко говоря, сильно преувеличена.
K>Чтобы вам проблему увидеть сколько лет потребуется?
Может и пару часов, если вы сможете привести вменяемый пример.
S>>Это все хорошо, но вот только не имеет отношения к вашему утверждению про "Один универсальный цикл на все случаи жизни."
K>Ну хорошо. Этот цикл вы предлагаете писать на итераторах. А другие циклы в программе на чем писать?
Зависит от ситуации, ваш К.О.
Так же ваш К.О. в очередной раз подчеркивает, насколько вы верите в непогрешимость собственного мнения, делая заявления типа "Один универсальный цикл на все случаи жизни." Которые по факту являются выдачей желаемого за действительное, в лучшем случае.
K>Вот насколько я знаю в ФБ своя С++ библиотека. Или по вашему там тоже одни малолетние дебилы неосиляторы?
А вы, когда захотите "малолетнего дебила" найти, лучше в зеркало посмотрите.
K>А то что циклы в программе могут быть разными это для вас открытие?
Вы опять пытаетесь подменить тему. Я нигде не утверждал, что все нужно делать на итераторах. Так что не приписывайте мне свои заблуждения.
K>Впрочем все что нужно я уже написал в абзаце выше.
Главное, что вы написали убогий пример и продемонстрировали незнание STL. А какие глупые слова вы вокруг можете наворачивать уже давно известно.
K>Для вашего примера нужно просто взять знаковый индекс int found_item = -1; и после цикла проверить if (found_item >= 0) K>Смотрите как легко становится жить если тип индекса был выбран правильно.
Для идиотов специально: там дело не в индексах, индексы никак не препятствуют сохранению ссылок на содержимое контейнера. И это глобальная проблема C++, решение для которой сейчас проходит проверку временем в Rust-е.
K>Вам все равно придется использовать индекс элемента, а т.к. в std он беззнаковый еще и заворачивать его в std::optional K>Вот так с кривым stl вы автоматически получаете кривизну на пустом месте.
Вы правда не видите других альтернатив std::optional?
Впрочем, наверняка не видите.
K>>>пример со storage и storage::blob был исчерпывающим, просто вы решили прикинутся шлангом и продолжить отрицание реальности.
S>>Нет. Вам были заданы вопросы, на которые вы отвечать отказались, т.е. слились. Посему незачет. Наличие проблемы вы не показали.
K>Почему-то все участники обсуждения все поняли, в отличии от вас.
Вы не с другими участниками эту тему обсуждали, а со мной. Мне вы не ответили.
K>Так что это ваши проблемы.
У меня нет проблем. Это вы видите проблему с отстутствием forward declaration для вложенных типов. Но продемонстрировать не можете.
K>А это что по вашему? void foo(Storage::Blob *blob); здесь черным по белому используется опережающее описание. Вы извините в шары долбитесь?
Это не использование Storage::Blob. У вас здесь идиома opaque pointer. А в ней этот самый opaque pointer может быть чем угодно. И для opaque pointer вовсе не обязательно показывать пользователю ни класс Storage, ни класс Blob. Можно хоть void* здесь применять, хоть типизированные обертки вокруг void*.
Так что еще раз, где использование Storage::Blob?
K>А вами продемонстрировано непонимание материала.
Если под материалом подразумеваются ваши пируэты с обсуждаемыми темами, то да, следить за ними сложно.
K>Что же касается незнания stl то мне нет и нужды знать то, что я не использую и не планирую использовать.
Т.е. вы признаете, что делаете резкие оценки в адрес того, чего не знаете?
Здравствуйте, Kluev, Вы писали:
K>>>В обоих случаях переполнение приведет к ошибочному ходу выполнения программы. BFE>>Нет, конечно. На переполнение беззнаковых можно закладываться, а вот на переполнение знаковых — нет.
K>С переполнением беззнаковых сложнее работать, т.к. при переполнении у вас будет валидный индекс 0
Вот именно, что точно известно, что будет в отличии от знаковых целых.
K>а со знаковыми вы уйдете в отрицательную область невалидных индексов.
Не-а. При переполнении знакового целого вы уйдёте в область неопределённого поведения:
Note: Unsigned arithmetic does not overflow. Overflow for
signed arithmetic yields undefined behavior (7.1). —end note
7.1/4
If during the evaluation of an expression, the result is not mathematically defined or not in the range of
representable values for its type, the behavior is undefined.
K>>>Но случаев когда переполнение возможно в беззнаковой арифметике однозначно больше. BFE>>Конечно случаев больше и поэтому с беззнаковыми переменными программы лучше отлажены, так как выявление ошибки происходит практически сразу, а не через 2147483647 операций. K>а через 4294967296 операций с беззнаковыми что происходит?
Будет 0 (если uint32_t) и с переменной можно продолжать работать.
Здравствуйте, so5team, Вы писали:
TB>>По эффективности — без разницы. Любой вменяемый компилятор справится.
S>https://godbolt.org/z/8PqEEE -- что-то у меня выходит разный выхлоп. Может покажете, как получить эквивалентные результаты?
Чёто ужас какой-то(
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
BFE>> так как выявление ошибки происходит практически сразу, а не через 2147483647 операций. TB>В паралельной вселенной, где массивы большие-пребольшие...
...думал программист из Microsoft, но коварные производители жестких дисков выпустили сделали 3TB и случился Epic fail. А вообще вот: Как наступить на грабли 32 раза или этапы большого пути.
Наоборот, в реальной вселенной, где массивы маленькие, как только unsigned уходит под ноль программист сразу ловит ошибку. Так что переполнение вниз ловится сразу.
А вот с signed всё работает и тесты проходят..., но много позже, лет через -цать, когда размер файла данных переваливает через два гигабайта, программа начинает сбоить...
Впрочем, верхнее переполнение unsigned приводит к тем же проблемам и почти никто их не отслеживает.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Kluev, Вы писали:
S>>>Так вы и не показали проблемы. Раз проблемы нет, то и исправлять нечего.
K>>Эту проблему даже в комитете увидели. Спустя всего 20 лет. Ссылку уже постили http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0289r0.pdf
S>Увидели и сказали "да и х с ним". Что как бы говорит, что актуальность этой проблемы, мягко говоря, сильно преувеличена.
Т.е. баги в языке исправлять ненужно, лучше наплодить побольше фич и побольше новых багов.
K>>Чтобы вам проблему увидеть сколько лет потребуется?
S>Может и пару часов, если вы сможете привести вменяемый пример.
Вменяемость понятие субьективное. Вам была показана невозможность использования опережающего описания вложенного класса. Этого вполне достаточно.
S>>>Это все хорошо, но вот только не имеет отношения к вашему утверждению про "Один универсальный цикл на все случаи жизни."
K>>Ну хорошо. Этот цикл вы предлагаете писать на итераторах. А другие циклы в программе на чем писать?
S>Зависит от ситуации, ваш К.О. S>Так же ваш К.О. в очередной раз подчеркивает, насколько вы верите в непогрешимость собственного мнения, делая заявления типа "Один универсальный цикл на все случаи жизни." Которые по факту являются выдачей желаемого за действительное, в лучшем случае.
K>>Вот насколько я знаю в ФБ своя С++ библиотека. Или по вашему там тоже одни малолетние дебилы неосиляторы?
S>Так они STL не заменяют, а используют: https://github.com/facebook/folly/blob/15f1d999e449fc145f77c3b8a94240981d837d74/folly/experimental/StringKeyedSet.h#L40
В том числе и заменяют. Как минимум классы вектор и стринг.
S>Главное, что вы написали убогий пример и продемонстрировали незнание STL.
Какая трагедия))) Незнание того что тебе не нужно. Что касается примера, то как вы могли сами убедится с list он будет вполне корректно работать. Компилятор не проверяет корректно ли написан stl код. А значит что при написании такого кода весь микроменеджмент ложится на вас. Любой программист может ошибиться в таком коде по невнимательности, а потом поиметь проблемы времени выполнения при переходе на vector. С моей точки зрения это слишком избыточно. Кроме своего кода написать заниматся микроменеджментом от стл и при этом не иметь никаких плюсов и гарантий.
S>Для идиотов специально: там дело не в индексах, индексы никак не препятствуют сохранению ссылок на содержимое контейнера. И это глобальная проблема C++, решение для которой сейчас проходит проверку временем в Rust-е.
Мы сейчас обсуждаем С++ и его проблемы.
K>>Вам все равно придется использовать индекс элемента, а т.к. в std он беззнаковый еще и заворачивать его в std::optional K>>Вот так с кривым stl вы автоматически получаете кривизну на пустом месте.
S>Вы правда не видите других альтернатив std::optional?
Альтернатив множество вплоть до вызова use_item прямо в теле цикла, разделение циклов на два и т.п. Я не телепат чтобы угадывать какую именно альтернативы вы выбрали.
S>Впрочем, наверняка не видите.
K>>>>пример со storage и storage::blob был исчерпывающим, просто вы решили прикинутся шлангом и продолжить отрицание реальности.
S>>>Нет. Вам были заданы вопросы, на которые вы отвечать отказались, т.е. слились. Посему незачет. Наличие проблемы вы не показали.
K>>Почему-то все участники обсуждения все поняли, в отличии от вас.
S>Вы не с другими участниками эту тему обсуждали, а со мной. Мне вы не ответили.
Не ответил потому что посчитал их не существенными. Баг языка был показан однозначно. А на демагогию у меня времени нет.
K>>Так что это ваши проблемы.
S>У меня нет проблем. Это вы видите проблему с отстутствием forward declaration для вложенных типов. Но продемонстрировать не можете.
K>>А это что по вашему? void foo(Storage::Blob *blob); здесь черным по белому используется опережающее описание. Вы извините в шары долбитесь?
S>Это не использование Storage::Blob. У вас здесь идиома opaque pointer. А в ней этот самый opaque pointer может быть чем угодно. И для opaque pointer вовсе не обязательно показывать пользователю ни класс Storage, ни класс Blob. Можно хоть void* здесь применять, хоть типизированные обертки вокруг void*.
S>Так что еще раз, где использование Storage::Blob?
Pointer declarator: the declaration S* D; declares D as a pointer to the type determined by decl-specifier-seq S.
Storage::Blob это тот самый тип который используется в Pointer declaration, и которым мы не можем воспользоватся из-за недостаточной поддержки опережающего описания вложенных классов.
K>>А вами продемонстрировано непонимание материала.
S>Если под материалом подразумеваются ваши пируэты с обсуждаемыми темами, то да, следить за ними сложно.
K>>Что же касается незнания stl то мне нет и нужды знать то, что я не использую и не планирую использовать.
S>Т.е. вы признаете, что делаете резкие оценки в адрес того, чего не знаете?
Знаю достаточно чтобы не использовать. Запаха и вида вполне достаточно.
BFE>А вот с signed всё работает и тесты проходят..., но много позже, лет через -цать, когда размер файла данных переваливает через два гигабайта, программа начинает сбоить... BFE>Впрочем, верхнее переполнение unsigned приводит к тем же проблемам и почти никто их не отслеживает.
