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

V>>Мы уже обсуждали это не раз, и ты как раз отвечаешь на суть того, с чем все (или почти все) согласились — "разница" должна быть знаковой.
S>Угу. Гляжу в книгу, вижу фигу.

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

Но у него и сообщества немного разные цели, увы.
Автору языка хочется увеличить аудиторию языка за счёт новичков, а сообществу хочется иметь эффективный язык и эффективные стандартные библиотеки.

Почему конкретнос в span<> использутся знаковые индексы — потому что это смещения, для которых как раз знаковые и пригодны, о чём я сразу же и сказал, а ты побежал спорить от "недостаточной компетенции" (С) Синклер.


V>>Я ж показал рядом, как можно корректно расписать взаимодействие знаковых и беззнаковых чисел:
S>Можно, но арифметика уже устроена определённым образом. И её поменять на вашу, увы, не получится.

Библиотечный подход еще никто не отменял.


V>>Это до тех пор, пока нет приличного оптимизатора.
S>Нет, это напрямую запрещено стандартом.

Да ничего там не запрещено:

In an unchecked context, overflows are ignored and any high-order bits that do not fit in the destination type are discarded.

Стандарты имеют обыкновение развиваться — UB при переполнение знакового далеко не сразу в плюсах появился.

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

В сегодняшних плюсах — это консенсус производителей процессоров и огромного сообщества разработчиков на С/С++, где размер сообщества значительно больше размера сообщества дотнетчиков.

Просто ваша технология в самом начале пути — она стала толком развиваться примерно с 2018/2019 гг, еще слишком мало времени прошло... но уже так много изменений, в сравнении с застоем предыдущих почти 20-ти лет, бгг...


V>>А когда появится, то будет что-то типа такого поведения под x64:
V>>

V>>    public static void Main(string[] args)
V>>    {
V>>        static bool IsMax(int i) {
V>>            return (i + 1u) < i;
V>>        }
        
V>>        Console.WriteLine(IsMax(0x7FFFFFFF));
V>>    }
V>>

V>>бгг...
S>Никогда такого поведения не будет.

Это не тебе решать.


S>И приведённое вами поведение чётко описано в стандарте.

Моё "приведённое поведение" лишь демонстрирует суть проблемы (если кто еще не уловил, почему в твоей версии были oops) — часто в железе выгодней оперировать размером в слово, чем в полуслово с постоянной коррекцией результата или с вызовом инструкций с длинными префиксами, как это происходит для инструкций в полуслово для intel-архитектуры.


S>Поэтому вот этот код даст false хоть в первом дотнете, хоть в девятом, и вне зависимости от дебаг/релиз режима.

Хосподя, вот же ж от тебя чудеса тугости порой.
Это была просто демонстрация того, что может однажды начать происходить в таком коде при агрессивной оптимизации:

    public static void Main(string[] args)
    {
        static bool IsMax(int i) {
            return (i + 1) < i;
        }
        
        Console.WriteLine(IsMax(0x7FFFFFFF));
    }

Я воспользовался для демонстрации явно описанными правилами продвижения типов в арифметике языка C#, конечно, поэтому 1u.

Учитывая, что за десятки постов обсуждения с коллегой никто из вас так и не догадался, что происходит и почему именно так — я посчитал нужным продемонстрировать происходящее явным образом.


S>И в любой следующей версии дотнета продолжит выдавать false.
S>А код, где к i прибавляется знаковая единица, продолжит выдавать true.

Это не тебе решать.

Ведь настоящее более-менее работающее без приседаний AOT впервые вышло лишь недавно — в 8-м дотнете.
С почином, как грится.

Лично я запасся попкорном и наблюдаю — будут его оптимизировать или оставят детской игрушкой, которой дотнет и был все эти 20+ лет?
Ставлю на то, что под давлением сообщества и постепенным отмиранием авторитета людей твоего пошиба, дотнет, таки, начнут по-людски оптимизировать.

А значит, гарантий для unchecked-арифметики не будет.


S>Ваши бугагашечки — просто роспись в некомпетентности, увы.

Насчёт некомпетентности вышло жалко, на фоне той дичи, что вы с коллегой несли в течении примерно 50-ти постов.
Если б я тебя носом не ткнул, ты бы так и не понял что происходит.
Ты еще буквально сообщение назад гоношился, хотя уже сидел в луже:
https://www.rsdn.org/forum/flame.comp/8734528.1

Парадокс Блаба он такой, сцуко, подлый где-то... ))


V>>Это официальная причина от непосредственных разработчиков дотнета.
S>И с кем из непосредственных разработчиков дотнета вам довелось пообщаться?

Со всеми тремя из их официальной книги об истории и ходе разработки дотнета.
Уже не в первый раз тебе рекомендую, а то витаешь в облаках, несёшь дичь какую-то из пальца насосанную.


V>>Я даже не могу придумать реальной задачи, которую стоит решать таким образом, потому что в таких задачах всегда удобней беззнаковое, т.е. просто набор бит.
S>

Так будет задача или нет?


V>>И ты тоже не придумаешь такой задачи, просто разводишь своё обычное пустопорожнее ля-ля-ля.
S> Задачу с усреднением трёх интов, я так понимаю, вы тактично решили своим вниманием обойти.

И чем там поможет знаковое в сравнении с беззнаковым?
И чем там поможет дотнет в режиме unchecked?
Там тупая потеря результата, если не удаётся расширить промежуточное значение (я же тебе же об этом же и отвечал ).

И тем забавнее твой смайл здесь:

V>>А теперь правильный ответ:
V>>Знаковое переполнения в 99.9% случаев указывает на потерю результата, т.е. на ошибку программы.

V>>Поэтому, важность детерминированного поведения в случае знакового переполнения примерно нулевая.
V>>Да всем насрать, собсно.
S>

Ключевое ты вырезал, оставил только последние две строчки, вот такое ты трусло и жалкий манипулятор, бгг.
Спасибо, поднял мне настроение, я непроизвольно заржал в голос в этом месте. ))

Я ему про потерю результата вычислений, он мне про нахождение средних, где как раз результат потенциально теряется.
— Ты куда? В баню?
— Да нет, в баню!

Комедиант, блин.


V>>Любая непродуманная дичь вызвала бы бесконечную по объёму реакцию.
S>Ну так она и вызывает. Просто вы в своём тепличном мирке ничего этого не видите.

Дичь была от вас, "недостаточно компетентных" (С) Синклер.

Но при чём тут остальные, которые стараются избегать переполнений при вычислениях?

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

V>>Мы уже обсуждали это не раз, и ты как раз отвечаешь на суть того, с чем все (или почти все) согласились — "разница" должна быть знаковой.
S>Угу. Гляжу в книгу, вижу фигу.

Это у тебя позднее зажигание просто, эта тема была давно уже обсосана.
К тому же, Страуструп ничего не решает в деле разработки стандартных библиотек, решает комитет и реакция сообщества.
вот Страуструп и пытается обращаться к сообществу.

Но у него и сообщества немного разные цели, увы.
Автору языка хочется увеличить аудиторию языка за счёт новичков, а сообществу хочется иметь эффективный язык и эффективные стандартные библиотеки.

Почему конкретнос в span<> использутся знаковые индексы — потому что это смещения, для которых как раз знаковые и пригодны, о чём я сразу же и сказал, а ты побежал спорить от "недостаточной компетенции" (С) Синклер.


V>>Я ж показал рядом, как можно корректно расписать взаимодействие знаковых и беззнаковых чисел:
S>Можно, но арифметика уже устроена определённым образом. И её поменять на вашу, увы, не получится.

Библиотечный подход еще никто не отменял.


V>>Это до тех пор, пока нет приличного оптимизатора.
S>Нет, это напрямую запрещено стандартом.

Да ничего там не запрещено:

In an unchecked context, overflows are ignored and any high-order bits that do not fit in the destination type are discarded.

Стандарты имеют обыкновение развиваться — UB при переполнение знакового далеко не сразу в плюсах появился.

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

В сегодняшних плюсах — это консенсус производителей процессоров и огромного сообщества разработчиков на С/С++, где размер сообщества значительно больше размера сообщества дотнетчиков.

Просто ваша технология в самом начале пути — она стала толком развиваться примерно с 2018/2019 гг, еще слишком мало времени прошло... но уже так много изменений, в сравнении с застоем предыдущих почти 20-ти лет, бгг...


V>>А когда появится, то будет что-то типа такого поведения под x64:
V>>

V>>    public static void Main(string[] args)
V>>    {
V>>        static bool IsMax(int i) {
V>>            return (i + 1u) < i;
V>>        }
        
V>>        Console.WriteLine(IsMax(0x7FFFFFFF));
V>>    }
V>>

V>>бгг...
S>Никогда такого поведения не будет.

Это не тебе решать.


S>И приведённое вами поведение чётко описано в стандарте.

Моё "приведённое поведение" лишь демонстрирует суть проблемы (если кто еще не уловил, почему в твоей версии были oops) — часто в железе выгодней оперировать размером в слово, чем в полуслово с постоянной коррекцией результата или с вызовом инструкций с длинными префиксами, как это происходит для инструкций в полуслово для intel-архитектуры.


S>Поэтому вот этот код даст false хоть в первом дотнете, хоть в девятом, и вне зависимости от дебаг/релиз режима.

Хосподя, вот же ж от тебя чудеса тугости порой.
Это была просто демонстрация того, что может однажды начать происходить в таком коде при агрессивной оптимизации:

    public static void Main(string[] args)
    {
        static bool IsMax(int i) {
            return (i + 1) < i;
        }
        
        Console.WriteLine(IsMax(0x7FFFFFFF));
    }

Я воспользовался для демонстрации явно описанными правилами продвижения типов в арифметике языка C#, конечно, поэтому 1u.

Учитывая, что за десятки постов обсуждения с коллегой никто из вас так и не догадался, что происходит и почему именно так — я посчитал нужным продемонстрировать происходящее явным образом.


S>И в любой следующей версии дотнета продолжит выдавать false.
S>А код, где к i прибавляется знаковая единица, продолжит выдавать true.

Это не тебе решать.

Ведь настоящее более-менее работающее без приседаний AOT впервые вышло лишь недавно — в 8-м дотнете.
С почином, как грится.

Лично я запасся попкорном и наблюдаю — будут его оптимизировать или оставят детской игрушкой, которой дотнет и был все эти 20+ лет?
Ставлю на то, что под давлением сообщества и постепенным отмиранием авторитета людей твоего пошиба, дотнет, таки, начнут по-людски оптимизировать.

А значит, гарантий для unchecked-арифметики не будет.


S>Ваши бугагашечки — просто роспись в некомпетентности, увы.

Насчёт некомпетентности вышло жалко, на фоне той дичи, что вы с коллегой несли в течении примерно 50-ти постов.
Если б я тебя носом не ткнул, ты бы так и не понял что происходит.
Ты еще буквально сообщение назад гоношился, хотя уже сидел в луже:
https://www.rsdn.org/forum/flame.comp/8734528.1

Парадокс Блаба он такой, сцуко, подлый где-то... ))


V>>Это официальная причина от непосредственных разработчиков дотнета.
S>И с кем из непосредственных разработчиков дотнета вам довелось пообщаться?

Со всеми тремя из их официальной книги об истории и ходе разработки дотнета.
Уже не в первый раз тебе рекомендую, а то витаешь в облаках, несёшь дичь какую-то из пальца насосанную.


V>>Я даже не могу придумать реальной задачи, которую стоит решать таким образом, потому что в таких задачах всегда удобней беззнаковое, т.е. просто набор бит.
S>

Так будет задача или нет?


V>>И ты тоже не придумаешь такой задачи, просто разводишь своё обычное пустопорожнее ля-ля-ля.
S> Задачу с усреднением трёх интов, я так понимаю, вы тактично решили своим вниманием обойти.

И чем там поможет знаковое в сравнении с беззнаковым?
И чем там поможет дотнет в режиме unchecked?
Там тупая потеря результата, если не удаётся расширить промежуточное значение (я же тебе же об этом же и отвечал ).

И тем забавнее твой смайл здесь:

V>>А теперь правильный ответ:
V>>Знаковое переполнения в 99.9% случаев указывает на потерю результата, т.е. на ошибку программы.

V>>Поэтому, важность детерминированного поведения в случае знакового переполнения примерно нулевая.
V>>Да всем насрать, собсно.
S>

Ключевое ты вырезал, оставил только последние две строчки, вот такое ты трусло и жалкий манипулятор, бгг.
Спасибо, поднял мне настроение, я непроизвольно заржал в голос в этом месте. ))

Я ему про потерю результата вычислений, он мне про нахождение средних, где как раз результат потенциально теряется.
— Ты куда? В баню?
— Да нет, в баню!

Комедиант, блин.


V>>Любая непродуманная дичь вызвала бы бесконечную по объёму реакцию.
S>Ну так она и вызывает. Просто вы в своём тепличном мирке ничего этого не видите.

Дичь была от вас, "недостаточно компетентных" (С) Синклер.

Но при чём тут остальные, которые стараются избегать переполнений при вычислениях?