Сообщение Re[27]: Carbon от 19.04.2024 19:09
Изменено 19.04.2024 19:33 vdimas
Re[27]: Carbon
Здравствуйте, Sinclair, Вы писали:
V>>Мы уже обсуждали это не раз, и ты как раз отвечаешь на суть того, с чем все (или почти все) согласились — "разница" должна быть знаковой.
S>Угу. Гляжу в книгу, вижу фигу.
Это у тебя позднее зажигание просто, эта тема была давно уже обсосана.
К тому же, Страуструп ничего не решает в деле разработки стандартных библиотек, решает комитет и реакция сообщества.
вот Страуструп и пытается обращаться к сообществу.
Но у него и сообщества немного разные цели, увы.
Автору языка хочется увеличить аудиторию языка за счёт новичков, а сообществу хочется иметь эффективный язык и эффективные стандартные библиотеки.
Почему конкретнос в span<> использутся знаковые индексы — потому что это смещения, для которых как раз знаковые и пригодны, о чём я сразу же и сказал, а ты побежал спорить от "недостаточной компетенции" (С) Синклер.
V>>Я ж показал рядом, как можно корректно расписать взаимодействие знаковых и беззнаковых чисел:
S>Можно, но арифметика уже устроена определённым образом. И её поменять на вашу, увы, не получится.
Библиотечный подход еще никто не отменял.
V>>Это до тех пор, пока нет приличного оптимизатора.
S>Нет, это напрямую запрещено стандартом.
Да ничего там не запрещено:
Стандарты имеют обыкновение развиваться — UB при переполнение знакового далеко не сразу в плюсах появился.
"destination type" для переменной в памяти или возвращаемого значения метода это одно, а для промежуточного значения при вычислении формулы унутре регистров может быть другим.
В сегодняшних плюсах — это консенсус производителей процессоров и огромного сообщества разработчиков на С/С++, где размер сообщества значительно больше размера сообщества дотнетчиков.
Просто ваша технология в самом начале пути — она стала толком развиваться примерно с 2018/2019 гг, еще слишком мало времени прошло... но уже так много изменений, в сравнении с застоем предыдущих почти 20-ти лет, бгг...
V>>А когда появится, то будет что-то типа такого поведения под x64:
V>>
V>>бгг...
S>Никогда такого поведения не будет.
Это не тебе решать.
S>И приведённое вами поведение чётко описано в стандарте.
Моё "приведённое поведение" лишь демонстрирует суть проблемы (если кто еще не уловил, почему в твоей версии были oops) — часто в железе выгодней оперировать размером в слово, чем в полуслово с постоянной коррекцией результата или с вызовом инструкций с длинными префиксами, как это происходит для инструкций в полуслово для intel-архитектуры.
S>Поэтому вот этот код даст false хоть в первом дотнете, хоть в девятом, и вне зависимости от дебаг/релиз режима.
Хосподя, вот же ж от тебя чудеса тугости порой.
Это была просто демонстрация того, что может однажды начать происходить в таком коде при агрессивной оптимизации:
Я воспользовался для демонстрации явно описанными правилами продвижения типов в арифметике языка C#, конечно, поэтому 1u.
Учитывая, что за десятки постов обсуждения с коллегой никто из вас так и не догадался, что происходит и почему именно так — я посчитал нужным продемонстрировать происходящее явным образом.
S>И в любой следующей версии дотнета продолжит выдавать false.
S>А код, где к i прибавляется знаковая единица, продолжит выдавать true.
Это не тебе решать.
Ведь настоящее более-менее работающее без приседаний AOT впервые вышло лишь недавно — в 8-м дотнете.
С почином, как грится.
Лично я запасся попкорном и наблюдаю — будут его оптимизировать или оставят детской игрушкой, которой дотнет и был все эти 20+ лет?
Ставлю на то, что под давлением сообщества и постепенным отмиранием авторитета людей твоего пошиба, дотнет, таки, начнут по-людски оптимизировать.
А значит, гарантий для unchecked-арифметики не будет.
Без обид, но таких как ты уже вымели из разработчиков дотнета поганой метлой, бгг...
Причём, процесс начался сверху — сначала выгнали руководителя дотнетного направления.
Примерно твой обоймы чувак, вылетел на воздух вместе со своей группой поддержки.
Потому что звиздеть — не мешки ворочать.
Дело надо делать, заниматься самолюбованием.
Стоило избавиться от сорняков, от зашедшей за границы приличия ангажированности — и сразу дело пошло.
Даже достаточно посмотреть на ускорения в 3-5 раз даже банальных преобразований ASCII<>UNICODE.
Кто мешал это сделать в течении предыдущих примерно 20-ти лет?
Некогда работать было?
Надо было вести блоги и просвещать "невежд"?
Посмотри на современное IO, на ref-структуры, ref-поля, readonly-методы (полные аналоги const-методов из С++), на in-аргументы методов (полные аналоги const T& args из плюсов), на where T is unmanaged, Span, ValueTask и т.д.
И это только за последние 3+ года, блин.
А что делали 20 лет до этого?
Можно заглянуть и поглубже, например, в SSL-стрим, где старое барахло тоже было выкинуто нахрен и переписано по-людски.
Но это уже совсем для тебя будет сложно, тут голову включать надо, проектировать потоки данных и моделировать различные ситуации в сети.
S>Ваши бугагашечки — просто роспись в некомпетентности, увы.
Да, да.
Насчёт некомпетентности вышло забавно, на фоне той дичи, что вы с коллегой несли в течении примерно 50-ти постов.
Если б я тебя носом не ткнул, ты бы так до сих пор и не понял что происходит в твоём коде.
Ты еще буквально сообщение назад гоношился, хотя уже сидел в луже:
https://www.rsdn.org/forum/flame.comp/8734528.1
Парадокс Блаба он такой, сцуко, подлый где-то... ))
V>>Это официальная причина от непосредственных разработчиков дотнета.
S>И с кем из непосредственных разработчиков дотнета вам довелось пообщаться?
Со всеми тремя из их официальной книги об истории и ходе разработки дотнета.
Уже не в первый раз тебе рекомендую, а то витаешь в облаках, несёшь дичь какую-то из пальца насосанную.
А они там тщательно описывали причины принятия тех или иных решений.
Ну, кроме делегатов, бгг...
В этом месте, походу, и сами поняли, что крупно облажались, неучи.
К сожалению, у всех трёх довольно однобокая карьера была.
Но одно дело проектировать АПИ COM — это чистейшая прикладная архитектурщина невысокого полёта (их предыдущий опыт).
И другое дело — проектировать систему базовых типов, определяя тем самым будущие сценарии их комбинаторики.
V>>Я даже не могу придумать реальной задачи, которую стоит решать таким образом, потому что в таких задачах всегда удобней беззнаковое, т.е. просто набор бит.
S>
Так будет задача или нет?
V>>И ты тоже не придумаешь такой задачи, просто разводишь своё обычное пустопорожнее ля-ля-ля.
S>
Задачу с усреднением трёх интов, я так понимаю, вы тактично решили своим вниманием обойти.
И чем там поможет знаковое в сравнении с беззнаковым?
И чем там поможет дотнет в режиме unchecked?
Там тупая потеря результата, если не удаётся расширить промежуточное значение (я же тебе же об этом же и отвечал ).
И тем забавнее твой смайл здесь:
Спасибо, поднял мне настроение, я непроизвольно заржал в голос в этом месте. ))
Я ему про потерю результата вычислений, он мне про нахождение средних, где как раз результат потенциально теряется.
Комедиант, блин.
V>>Любая непродуманная дичь вызвала бы бесконечную по объёму реакцию.
S>Ну так она и вызывает. Просто вы в своём тепличном мирке ничего этого не видите.
Дичь была от вас, "недостаточно компетентных" (С) Синклер.
Но при чём тут остальные, которые стараются избегать переполнений при вычислениях?
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-арифметики не будет.
Без обид, но таких как ты уже вымели из разработчиков дотнета поганой метлой, бгг...
Причём, процесс начался сверху — сначала выгнали руководителя дотнетного направления.
Примерно твой обоймы чувак, вылетел на воздух вместе со своей группой поддержки.
Потому что звиздеть — не мешки ворочать.
Дело надо делать, заниматься самолюбованием.
Стоило избавиться от сорняков, от зашедшей за границы приличия ангажированности — и сразу дело пошло.
Даже достаточно посмотреть на ускорения в 3-5 раз даже банальных преобразований ASCII<>UNICODE.
Кто мешал это сделать в течении предыдущих примерно 20-ти лет?
Некогда работать было?
Надо было вести блоги и просвещать "невежд"?
Посмотри на современное IO, на ref-структуры, ref-поля, readonly-методы (полные аналоги const-методов из С++), на in-аргументы методов (полные аналоги const T& args из плюсов), на where T is unmanaged, Span, ValueTask и т.д.
И это только за последние 3+ года, блин.
А что делали 20 лет до этого?
Можно заглянуть и поглубже, например, в SSL-стрим, где старое барахло тоже было выкинуто нахрен и переписано по-людски.
Но это уже совсем для тебя будет сложно, тут голову включать надо, проектировать потоки данных и моделировать различные ситуации в сети.
S>Ваши бугагашечки — просто роспись в некомпетентности, увы.
Да, да.
Насчёт некомпетентности вышло забавно, на фоне той дичи, что вы с коллегой несли в течении примерно 50-ти постов.
Если б я тебя носом не ткнул, ты бы так до сих пор и не понял что происходит в твоём коде.
Ты еще буквально сообщение назад гоношился, хотя уже сидел в луже:
https://www.rsdn.org/forum/flame.comp/8734528.1
Парадокс Блаба он такой, сцуко, подлый где-то... ))
V>>Это официальная причина от непосредственных разработчиков дотнета.
S>И с кем из непосредственных разработчиков дотнета вам довелось пообщаться?
Со всеми тремя из их официальной книги об истории и ходе разработки дотнета.
Уже не в первый раз тебе рекомендую, а то витаешь в облаках, несёшь дичь какую-то из пальца насосанную.
А они там тщательно описывали причины принятия тех или иных решений.
Ну, кроме делегатов, бгг...
В этом месте, походу, и сами поняли, что крупно облажались, неучи.
К сожалению, у всех трёх довольно однобокая карьера была.
Но одно дело проектировать АПИ COM — это чистейшая прикладная архитектурщина невысокого полёта (их предыдущий опыт).
И другое дело — проектировать систему базовых типов, определяя тем самым будущие сценарии их комбинаторики.
V>>Я даже не могу придумать реальной задачи, которую стоит решать таким образом, потому что в таких задачах всегда удобней беззнаковое, т.е. просто набор бит.
S>
Так будет задача или нет?
V>>И ты тоже не придумаешь такой задачи, просто разводишь своё обычное пустопорожнее ля-ля-ля.
S>
Задачу с усреднением трёх интов, я так понимаю, вы тактично решили своим вниманием обойти. И чем там поможет знаковое в сравнении с беззнаковым?
И чем там поможет дотнет в режиме unchecked?
Там тупая потеря результата, если не удаётся расширить промежуточное значение (я же тебе же об этом же и отвечал
).И тем забавнее твой смайл здесь:
Ключевое-выделенное ты вырезал, оставил только последние две строчки, вот такое ты трусло и жалкий манипулятор, бгг.V>>А теперь правильный ответ:
V>>Знаковое переполнения в 99.9% случаев указывает на потерю результата, т.е. на ошибку программы.
V>>Поэтому, важность детерминированного поведения в случае знакового переполнения примерно нулевая.
V>>Да всем насрать, собсно.
S>
Спасибо, поднял мне настроение, я непроизвольно заржал в голос в этом месте. ))
Я ему про потерю результата вычислений, он мне про нахождение средних, где как раз результат потенциально теряется.
- Ты куда? В баню?
— Да нет, в баню!
Комедиант, блин.
V>>Любая непродуманная дичь вызвала бы бесконечную по объёму реакцию.
S>Ну так она и вызывает. Просто вы в своём тепличном мирке ничего этого не видите.
Дичь была от вас, "недостаточно компетентных" (С) Синклер.
Но при чём тут остальные, которые стараются избегать переполнений при вычислениях?
Re[27]: Carbon
Здравствуйте, Sinclair, Вы писали:
V>>Мы уже обсуждали это не раз, и ты как раз отвечаешь на суть того, с чем все (или почти все) согласились — "разница" должна быть знаковой.
S>Угу. Гляжу в книгу, вижу фигу.
Это у тебя позднее зажигание просто, эта тема была давно уже обсосана.
К тому же, Страуструп ничего не решает в деле разработки стандартных библиотек, решает комитет и реакция сообщества.
вот Страуструп и пытается обращаться к сообществу.
Но у него и сообщества немного разные цели, увы.
Автору языка хочется увеличить аудиторию языка за счёт новичков, а сообществу хочется иметь эффективный язык и эффективные стандартные библиотеки.
Почему конкретнос в span<> использутся знаковые индексы — потому что это смещения, для которых как раз знаковые и пригодны, о чём я сразу же и сказал, а ты побежал спорить от "недостаточной компетенции" (С) Синклер.
V>>Я ж показал рядом, как можно корректно расписать взаимодействие знаковых и беззнаковых чисел:
S>Можно, но арифметика уже устроена определённым образом. И её поменять на вашу, увы, не получится.
Библиотечный подход еще никто не отменял.
V>>Это до тех пор, пока нет приличного оптимизатора.
S>Нет, это напрямую запрещено стандартом.
Да ничего там не запрещено:
Стандарты имеют обыкновение развиваться — UB при переполнение знакового далеко не сразу в плюсах появился.
"destination type" для переменной в памяти или возвращаемого значения метода это одно, а для промежуточного значения при вычислении формулы унутре регистров может быть другим.
В сегодняшних плюсах — это консенсус производителей процессоров и огромного сообщества разработчиков на С/С++, где размер сообщества значительно больше размера сообщества дотнетчиков.
Просто ваша технология в самом начале пути — она стала толком развиваться примерно с 2018/2019 гг, еще слишком мало времени прошло... но уже так много изменений, в сравнении с застоем предыдущих почти 20-ти лет, бгг...
V>>А когда появится, то будет что-то типа такого поведения под x64:
V>>
V>>бгг...
S>Никогда такого поведения не будет.
Это не тебе решать.
S>И приведённое вами поведение чётко описано в стандарте.
Моё "приведённое поведение" лишь демонстрирует суть проблемы (если кто еще не уловил, почему в твоей версии были oops) — часто в железе выгодней оперировать размером в слово, чем в полуслово с постоянной коррекцией результата или с вызовом инструкций с длинными префиксами, как это происходит для инструкций в полуслово для intel-архитектуры.
S>Поэтому вот этот код даст false хоть в первом дотнете, хоть в девятом, и вне зависимости от дебаг/релиз режима.
Хосподя, вот же ж от тебя чудеса тугости порой.
Это была просто демонстрация того, что может однажды начать происходить в таком коде при агрессивной оптимизации:
Я воспользовался для демонстрации явно описанными правилами продвижения типов в арифметике языка C#, конечно, поэтому 1u.
Учитывая, что за десятки постов обсуждения с коллегой никто из вас так и не догадался, что происходит и почему именно так — я посчитал нужным продемонстрировать происходящее явным образом.
S>И в любой следующей версии дотнета продолжит выдавать false.
S>А код, где к i прибавляется знаковая единица, продолжит выдавать true.
Это не тебе решать.
Ведь настоящее более-менее работающее без приседаний AOT впервые вышло лишь недавно — в 8-м дотнете.
С почином, как грится.
Лично я запасся попкорном и наблюдаю — будут его оптимизировать или оставят детской игрушкой, которой дотнет и был все эти 20+ лет?
Ставлю на то, что под давлением сообщества и постепенным отмиранием авторитета людей твоего пошиба, дотнет, таки, начнут по-людски оптимизировать.
А значит, гарантий для unchecked-арифметики не будет.
Без обид, но таких как ты уже вымели из разработчиков дотнета поганой метлой, бгг...
Причём, процесс начался сверху — сначала выгнали руководителя дотнетного направления.
Примерно твоей обоймы чувак, вылетел на воздух вместе со своей группой поддержки.
Потому что звиздеть — не мешки ворочать.
Дело надо делать, а не заниматься самолюбованием.
Стоило избавиться от сорняков, от зашедшей за границы приличия ангажированности — и сразу дело пошло.
Даже достаточно посмотреть на ускорения в 3-5 раз даже банальных преобразований ASCII<>UNICODE.
Кто мешал это сделать в течении предыдущих примерно 20-ти лет?
Некогда работать было?
Надо было вести блоги и просвещать "невежд"?
Посмотри на современное IO, на ref-структуры, ref-поля, readonly-методы (полные аналоги const-методов из С++), на in-аргументы методов (полные аналоги const T& args из плюсов), на where T is unmanaged, Span, ValueTask и т.д.
И это только за последние 3+ года, блин.
А что делали 20 лет до этого?
Можно заглянуть и поглубже, например, в SSL-стрим, где старое барахло тоже было выкинуто нахрен и переписано по-людски.
Но это уже совсем для тебя будет сложно, тут голову включать надо, проектировать потоки данных и моделировать различные ситуации в сети.
S>Ваши бугагашечки — просто роспись в некомпетентности, увы.
Да, да.
Насчёт некомпетентности вышло забавно, на фоне той дичи, что вы с коллегой несли в течении примерно 50-ти постов.
Если б я тебя носом не ткнул, ты бы так до сих пор и не понял что происходит в твоём коде.
Ты еще буквально сообщение назад гоношился, хотя уже сидел в луже:
https://www.rsdn.org/forum/flame.comp/8734528.1
Парадокс Блаба он такой, сцуко, подлый где-то... ))
V>>Это официальная причина от непосредственных разработчиков дотнета.
S>И с кем из непосредственных разработчиков дотнета вам довелось пообщаться?
Со всеми тремя из их официальной книги об истории и ходе разработки дотнета.
Уже не в первый раз тебе рекомендую, а то витаешь в облаках, несёшь дичь какую-то из пальца насосанную.
А они там тщательно описывали причины принятия тех или иных решений.
Ну, кроме делегатов, бгг...
В этом месте, походу, и сами поняли, что крупно облажались, неучи.
К сожалению, у всех трёх довольно однобокая карьера была.
Но одно дело проектировать АПИ COM — это чистейшая прикладная архитектурщина невысокого полёта (их предыдущий опыт).
И другое дело — проектировать систему базовых типов, определяя тем самым будущие сценарии их комбинаторики.
V>>Я даже не могу придумать реальной задачи, которую стоит решать таким образом, потому что в таких задачах всегда удобней беззнаковое, т.е. просто набор бит.
S>
Так будет задача или нет?
V>>И ты тоже не придумаешь такой задачи, просто разводишь своё обычное пустопорожнее ля-ля-ля.
S> Задачу с усреднением трёх интов, я так понимаю, вы тактично решили своим вниманием обойти.
И чем там поможет знаковое в сравнении с беззнаковым?
И чем там поможет дотнет в режиме unchecked?
Там тупая потеря результата, если не удаётся расширить промежуточное значение (я же тебе же об этом же и отвечал ).
И тем забавнее твой смайл здесь:
Спасибо, поднял мне настроение, я непроизвольно заржал в голос в этом месте. ))
Я ему про потерю результата вычислений, он мне про нахождение средних, где как раз результат потенциально теряется.
Комедиант, блин.
V>>Любая непродуманная дичь вызвала бы бесконечную по объёму реакцию.
S>Ну так она и вызывает. Просто вы в своём тепличном мирке ничего этого не видите.
Дичь была от вас, "недостаточно компетентных" (С) Синклер.
Но при чём тут остальные, которые стараются избегать переполнений при вычислениях?
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-арифметики не будет.
Без обид, но таких как ты уже вымели из разработчиков дотнета поганой метлой, бгг...
Причём, процесс начался сверху — сначала выгнали руководителя дотнетного направления.
Примерно твоей обоймы чувак, вылетел на воздух вместе со своей группой поддержки.
Потому что звиздеть — не мешки ворочать.
Дело надо делать, а не заниматься самолюбованием.
Стоило избавиться от сорняков, от зашедшей за границы приличия ангажированности — и сразу дело пошло.
Даже достаточно посмотреть на ускорения в 3-5 раз даже банальных преобразований ASCII<>UNICODE.
Кто мешал это сделать в течении предыдущих примерно 20-ти лет?
Некогда работать было?
Надо было вести блоги и просвещать "невежд"?
Посмотри на современное IO, на ref-структуры, ref-поля, readonly-методы (полные аналоги const-методов из С++), на in-аргументы методов (полные аналоги const T& args из плюсов), на where T is unmanaged, Span, ValueTask и т.д.
И это только за последние 3+ года, блин.
А что делали 20 лет до этого?
Можно заглянуть и поглубже, например, в SSL-стрим, где старое барахло тоже было выкинуто нахрен и переписано по-людски.
Но это уже совсем для тебя будет сложно, тут голову включать надо, проектировать потоки данных и моделировать различные ситуации в сети.
S>Ваши бугагашечки — просто роспись в некомпетентности, увы.
Да, да.
Насчёт некомпетентности вышло забавно, на фоне той дичи, что вы с коллегой несли в течении примерно 50-ти постов.
Если б я тебя носом не ткнул, ты бы так до сих пор и не понял что происходит в твоём коде.
Ты еще буквально сообщение назад гоношился, хотя уже сидел в луже:
https://www.rsdn.org/forum/flame.comp/8734528.1
Парадокс Блаба он такой, сцуко, подлый где-то... ))
V>>Это официальная причина от непосредственных разработчиков дотнета.
S>И с кем из непосредственных разработчиков дотнета вам довелось пообщаться?
Со всеми тремя из их официальной книги об истории и ходе разработки дотнета.
Уже не в первый раз тебе рекомендую, а то витаешь в облаках, несёшь дичь какую-то из пальца насосанную.
А они там тщательно описывали причины принятия тех или иных решений.
Ну, кроме делегатов, бгг...
В этом месте, походу, и сами поняли, что крупно облажались, неучи.
К сожалению, у всех трёх довольно однобокая карьера была.
Но одно дело проектировать АПИ COM — это чистейшая прикладная архитектурщина невысокого полёта (их предыдущий опыт).
И другое дело — проектировать систему базовых типов, определяя тем самым будущие сценарии их комбинаторики.
V>>Я даже не могу придумать реальной задачи, которую стоит решать таким образом, потому что в таких задачах всегда удобней беззнаковое, т.е. просто набор бит.
S>
Так будет задача или нет?
V>>И ты тоже не придумаешь такой задачи, просто разводишь своё обычное пустопорожнее ля-ля-ля.
S>
Задачу с усреднением трёх интов, я так понимаю, вы тактично решили своим вниманием обойти. И чем там поможет знаковое в сравнении с беззнаковым?
И чем там поможет дотнет в режиме unchecked?
Там тупая потеря результата, если не удаётся расширить промежуточное значение (я же тебе же об этом же и отвечал
).И тем забавнее твой смайл здесь:
Ключевое-выделенное ты вырезал, оставил только последние две строчки, вот такое ты трусло и жалкий манипулятор, бгг.V>>А теперь правильный ответ:
V>>Знаковое переполнения в 99.9% случаев указывает на потерю результата, т.е. на ошибку программы.
V>>Поэтому, важность детерминированного поведения в случае знакового переполнения примерно нулевая.
V>>Да всем насрать, собсно.
S>
Спасибо, поднял мне настроение, я непроизвольно заржал в голос в этом месте. ))
Я ему про потерю результата вычислений, он мне про нахождение средних, где как раз результат потенциально теряется.
- Ты куда? В баню?
— Да нет, в баню!
Комедиант, блин.
V>>Любая непродуманная дичь вызвала бы бесконечную по объёму реакцию.
S>Ну так она и вызывает. Просто вы в своём тепличном мирке ничего этого не видите.
Дичь была от вас, "недостаточно компетентных" (С) Синклер.
Но при чём тут остальные, которые стараются избегать переполнений при вычислениях?