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

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

K>>а со знаковыми вы уйдете в отрицательную область невалидных индексов.

S>Кто вам это гарантировал?

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

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

K>что и требовалось доказать
То, что с беззнаковыми ошибки встречаются два раза реже? Да, удалось.

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

BFE>То, что с беззнаковыми ошибки встречаются два раза реже? Да, удалось.

В 10 раз чаще. Продавливание под 0 будет случаться постоянно, приводя к трудноуловимым последствиям.

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

BFE>>То, что с беззнаковыми ошибки встречаются два раза реже? Да, удалось.
TB>В 10 раз чаще. Продавливание под 0 будет случаться постоянно, приводя к трудноуловимым последствиям.

Почему трудноуловимым?

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

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

BFE>>>То, что с беззнаковыми ошибки встречаются два раза реже? Да, удалось.
TB>>В 10 раз чаще. Продавливание под 0 будет случаться постоянно, приводя к трудноуловимым последствиям.

BFE>Почему трудноуловимым?

Ну потому что где и почему формула выдала число 10005000 вместо -1 — не всегда очевидно.

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

Ш>Комитет по стандартизации пора расстрелять. Такое ощущение, что эти дебилы никогда не писали софт сложнее hello world.
Они как раз писали. И понимают, что код в первую очередь нужно читать и уже во вторую — писать.

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

K>программист может сам себе гарантировать, в платформозависимом решении.

Увы, нет. Все может накрыться медным тазом просто после обновления компилятора.

K>а если вы думаете что ваши программы будут выполнятся вечно на всех новых платформах и новом железе, то я вас расстрою. еще при нашей жизни от них и эха не останется.

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

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

K>Т.е. баги в языке исправлять ненужно, лучше наплодить побольше фич и побольше новых багов.

Баги -- нужно. Но вы не смогли показать наличие бага.

K>Вам была показана невозможность использования опережающего описания вложенного класса.

Невозможность показана. Какие-либо следующие из этого проблемы -- нет.

K>Этого вполне достаточно.

Для тараканов в вашей голове, возможно.

S>>Так они STL не заменяют, а используют: https://github.com/facebook/folly/blob/15f1d999e449fc145f77c3b8a94240981d837d74/folly/experimental/StringKeyedSet.h#L40

K>В том числе и заменяют. Как минимум классы вектор и стринг.

Ага, а затем массово используют их же в unit-тестах для folly: https://github.com/facebook/folly/blob/c19c06e5f23d785e83752967326c3e948b336535/folly/futures/test/CollectTest.cpp#L37 и https://github.com/facebook/folly/blob/d2c64d94c7e892925a02a080c886ab3df3f5c937/folly/experimental/NestedCommandLineApp.h#L38

Ну и могли бы вы указать на оные замены? А то может речь идет о вещах типа small_vector и fixed_string?

K>Какая трагедия)))

Да. Как минимум это означает, что все ваши потуги можно смело и сразу отправлять в /dev/null.

S>>Для идиотов специально: там дело не в индексах, индексы никак не препятствуют сохранению ссылок на содержимое контейнера. И это глобальная проблема C++, решение для которой сейчас проходит проверку временем в Rust-е.

K>Мы сейчас обсуждаем С++ и его проблемы.

Для идиотов специально: там дело не в индексах, индексы никак не препятствуют сохранению ссылок на содержимое контейнера. И это глобальная проблема C++.

Так что от обсуждения проблем C++ мы никуда и не уходили, даже не смотря на то вы увидели в тексте слово Rust.

K>>>Вам все равно придется использовать индекс элемента, а т.к. в std он беззнаковый еще и заворачивать его в std::optional
K>>>Вот так с кривым stl вы автоматически получаете кривизну на пустом месте.

S>>Вы правда не видите других альтернатив std::optional?

K>Альтернатив множество вплоть до вызова use_item прямо в теле цикла, разделение циклов на два и т.п. Я не телепат чтобы угадывать какую именно альтернативы вы выбрали.

Вот даже вы видите более одной альтернативы, но при этом почему-то в качестве _моего_ решения описываете одно из самых неэффективных, с использованием std::optional. Что наводит на мысль, что вы за меня выдумываете какие-то тезисы, а потом их же старательно и опровергаете.

K>Не ответил потому что посчитал их не существенными. Баг языка был показан однозначно. А на демагогию у меня времени нет.

Т.е. вы не посчитали существенной информацию, которую у вас просил ваш собеседник? Ну что же, значит с диагнозом нет ошибки.

И если у вас нет времени на демагогию, то почему вы столько дней здесь ей занимаетесь?

S>>Это не использование Storage::Blob. У вас здесь идиома opaque pointer. А в ней этот самый opaque pointer может быть чем угодно. И для opaque pointer вовсе не обязательно показывать пользователю ни класс Storage, ни класс Blob. Можно хоть void* здесь применять, хоть типизированные обертки вокруг void*.

K>Прямо у вас под носом как обычно. И в void foo(Storage::Blob *blob) происходит не идиома, о самое обыкновенное Pointer declaration

ППц, вы хоть бы матчасть подучили. Хотя бы на уровне спорных формулировок из Wikipedia: https://en.wikipedia.org/wiki/Opaque_pointer

S>>Т.е. вы признаете, что делаете резкие оценки в адрес того, чего не знаете?

K>Знаю достаточно чтобы не использовать. Запаха и вида вполне достаточно.

То, что вы не используете STL, наверное, даже хорошо. Проблема в другом: если вы не знаете предмета разговора, то ни ваше мнение, ни ваши оценки ничего не стоят. Но, будучи "малолетним дебилом" вы старательно хотите донести до всех свое "веское мнение" по теме, в которой не разбираетесь.

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


K>А где реально нужны пространства имен? Приведите хоть один реальный случай случая когда нельзя было бы обойтись префиксами. Новшества вводят для удобства, а не только когда реально нужно. Кроме того forward declaration для вложенных классов это тот случай когда исправлять реально нужно, потому что это баг на уровне языка.

Интересно наблюдать за тем, как люди, сильно покалеченные программированием на Си и С++, называют багом языка то, что костыль для исправления настоящих багов языка не достаточно хорош.

Так вот, баг на уровне языка, это необходимость в forward declaration. Были бы нормальные модули, не нужно было бы этим заморачиваться. Надеюсь современный С++ придет к модулям рано или поздно. Он все больше и больше начинает быть похож на нормальный язык программирования без заморочек. Пусть комитету и потребовалось больше десяти лет, чтобы мы могли писать std::vector<std::pair<int, int>> вместо std::vector<std::pair<int, int> >.

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

K>И по вашему в том числе. Нотацию с префиксами вы сами забраковали постами выше, ну а класс storage в пространстве имен storage и комментариев не требует.

То-есть ты сам написал хрень с пространством имен storage и классом storage и теперь утверждаешь что это проблема языка? Кто мешает выбирать нормальные имена и нормально структурировать свой код? Отсутствие forward declaration для вложенных классов или отсутствие мозгов?

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

CK>Надеюсь современный С++ придет к модулям рано или поздно.

Так ведь модули уже стали частью грядущего C++20.
Или это не те модули?

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

K>программист может сам себе гарантировать, в платформозависимом решении. это вполне оправдано. а если вы думаете что ваши программы будут выполнятся вечно на всех новых платформах и новом железе, то я вас расстрою. еще при нашей жизни от них и эха не останется.

Компилятор имеет полное право вырезать к чертям твой код, который приводит к UB (а переполнение знакового целого это UB). Так как никакое поведение не гарантировано, можно выбрать любое!

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


S>А вообще речь шла о том, что кроме авторов STL есть разработчики, которые находят логичным использование беззнаковых чисел для размеров и индексов. Т.е. авторы STL вовсе не были "белыми воронами".

а кто-то находит логичным иметь возможность написать assert(ix >= 0)
вообще там кмк проблема не в переполнении а в том, что у тебя в приложении зачастую происходит сравнение знаковых и беззнаковых, и вот такой код как раз сложнее отлаживать и поддерживать, намного лучше когда все знаковое, никаких тебе лишних приведений типов и проверок на narrowing и тд

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


P>Ага, точно, спасибо.
P>Но, блин, это камень в огород плоскоземельниковзнакоразмерников — люди серьезно считают что это лучше для чтения и понимания?


тут знаковость не причем, чтобы понять как это работает, достаточно понимать как работает цикл for

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


S>А теперь представим, что в процессе сопровождения и оптимизации у вас points из вектора превратился в простой список или список чанков. И у вас больше нет индекса, зато есть итераторы, которые позволяют вам итерироваться по новому контейнеру последовательно.

представил вычислительную геометрию на std::list и

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

CK>в приложении зачастую происходит сравнение знаковых и беззнаковых

А откуда берется это самое "зачастую"?

Индексы и размерности беззнаковые. Соответственно, операции с ними такие же.

Знаковые числа используются в вычислениях, которые не относятся к индексации.

Соответственно, операции над индексами и другие вычисления просто не пересекаются.

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

S>Так ведь модули уже стали частью грядущего C++20.
S>Или это не те модули?

почти, они делают forward declaration нужным только в случае, если у тебя есть циклическая зависимость внутри описания самого модуля, что-то вроде

export module directio;

export namespace directio{

    class Blob;

    class File {
    public:
        std::vector<Blob> dma_read(vector<iovec>&& query);
    };

    class Blob {
    public:
        Blob(size_t);
    };
}

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

BFE>>Почему трудноуловимым?
TB>Ну потому что где и почему формула выдала число 10005000 вместо -1 — не всегда очевидно.

Это бывает только если мешать в выражениях знаковые и беззнаковые — во всех остальных случаях всё очевидно.