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

V>>Знаковые целые нужны редко, в основном для оперирования сущностями, близкому по смыслу к "разница", "текущий остаток/баланс", или для традиционного возврата кодов или признаков ошибок.
S>Угу. Вся индустрия идёт не в ногу, только vdimas идёт в ногу.

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

Например, смещение от некоего адреса — это и есть "разница".
И в языке это явно поддерживается для адресной арифметики, т.к. адреса можно складывать с положительными и отрицательными числами.

float data[42 + 42];
float * cursor = data + 42;
float value = cursor[-42];

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

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

Problems with unsigned
Mixing signed and unsigned numbers is a common source of confusion and bugs.

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

Я ж показал рядом, как можно корректно расписать взаимодействие знаковых и беззнаковых чисел:
https://www.rsdn.org/forum/flame.comp/8734308.1

Тебе заранее на всё ответили. ))


V>>У меня обсуждаемая проблема вечно вылазит в дотнете, бо системное АПИ расписано на знаковых, даже где это выглядит абсурдом.
S>Обсуждаемая проблема в дотнете вылезти не может, т.к. в нём знаковое переполнение не является UB.

Это до тех пор, пока нет приличного оптимизатора.
А когда появится, то будет что-то типа такого поведения под x64:

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

бгг...


V>>Причина известна — не во всех языках есть беззнаковый тип, поэтому платформа затачивалась на слабое звено. ))
S>Опять смелая догадка.

Это официальная причина от непосредственных разработчиков дотнета.


V>>Переполнения принято производить с беззнаковыми, а со знаковыми принято оперировать так, чтобы переполнения не возникало.
S>Не, просто 99% С++ программистов вообще не в курсе, что знаковое переполнение — это UB.

Продолжаешь себя топить.
Извини, но выдать такое мог только человек с не очень большим опытом в написании программ.

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

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

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

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


S>Большинство пребывают примерно в таком же заблуждении, как и вы — что это Implementation-defined.

Опять чухню несёшь какую-то.
Большинство считают переполнение знакового ошибкой программы.
Да какой большинство, хосподя... Практически все более-менее опытные программисты.

Ты бы хоть голову включил бы разок — стандарты C++ на сегодня принимаются наиболее тщательно и с самым широким обсуждением.
В обсуждении каждой мелочи (пусть чаще в режиме read-only, т.е. "контроль происходящего глазами") участвуют даже не десятки тысяч людей по всему миру, а сотни тыщ.
Любая непродуманная дичь вызвала бы бесконечную по объёму реакцию.

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

Зато сейчас, когда Core-версия разрабатывается прилюдно, с косяками в самом языке стало полегче.

Например, последний косяк C# был в уродской декомпозии типов для целей паттерн-матчинга.
Этот ужас был разработан еще для старого фреймворка за закрытыми дверями, ничего удивительного.
Сравни теперь с той элегантностью, которую разработали уже с привлечением сообщества для тех же целей уже в Core, ы?

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

V>>Знаковые целые нужны редко, в основном для оперирования сущностями, близкому по смыслу к "разница", "текущий остаток/баланс", или для традиционного возврата кодов или признаков ошибок.
S>Угу. Вся индустрия идёт не в ногу, только vdimas идёт в ногу.

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

Например, смещение от некоего адреса — это и есть "разница".
И в языке это явно поддерживается для адресной арифметики, т.к. адреса можно складывать с положительными и отрицательными числами.

float data[42 + 42];
float * cursor = data + 42;
float value = cursor[-42];

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

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

Problems with unsigned
Mixing signed and unsigned numbers is a common source of confusion and bugs.

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

Я ж показал рядом, как можно корректно расписать взаимодействие знаковых и беззнаковых чисел:
https://www.rsdn.org/forum/flame.comp/8734308.1

Тебе заранее на всё ответили. ))

Вдогоку здесь.
Страуструп не пытается в бумаге по ссылке решить вопросы эффективности или читабельности.
Он пытается решить вопрос снижения пресловутой "планки входа".

Даже взять вот это:

Checking signed 0<=x && x<max (often evaluated as (0<=x) & (x<max) to avoid branching) is not slower than unsigned x<max on a modern computer.

Это неверно для некоторых архитектур, для которых активно используют именно С/С++, т.к. для некоторых архитектур простое битовое сложение флагов искалечит первоначальное условие, и получится 0<x && x<max, что есть ошибка. Плюс компилятору потребуется сгенерировать код запоминания регистра флагов. Поэтому, для некоторых популярных архитектур там будет честный бранчинг, т.к. на уровне исходников всё-равно положено писать 0<=x && x<max.


V>>У меня обсуждаемая проблема вечно вылазит в дотнете, бо системное АПИ расписано на знаковых, даже где это выглядит абсурдом.
S>Обсуждаемая проблема в дотнете вылезти не может, т.к. в нём знаковое переполнение не является UB.

Это до тех пор, пока нет приличного оптимизатора.
А когда появится, то будет что-то типа такого поведения под x64:

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

бгг...


V>>Причина известна — не во всех языках есть беззнаковый тип, поэтому платформа затачивалась на слабое звено. ))
S>Опять смелая догадка.

Это официальная причина от непосредственных разработчиков дотнета.


V>>Переполнения принято производить с беззнаковыми, а со знаковыми принято оперировать так, чтобы переполнения не возникало.
S>Не, просто 99% С++ программистов вообще не в курсе, что знаковое переполнение — это UB.

Продолжаешь себя топить.
Извини, но выдать такое мог только человек с не очень большим опытом в написании программ.

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

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

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

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


S>Большинство пребывают примерно в таком же заблуждении, как и вы — что это Implementation-defined.

Опять чухню несёшь какую-то.
Большинство считают переполнение знакового ошибкой программы.
Да какой большинство, хосподя... Практически все более-менее опытные программисты.

Ты бы хоть голову включил бы разок — стандарты C++ на сегодня принимаются наиболее тщательно и с самым широким обсуждением.
В обсуждении каждой мелочи (пусть чаще в режиме read-only, т.е. "контроль происходящего глазами") участвуют даже не десятки тысяч людей по всему миру, а сотни тыщ.
Любая непродуманная дичь вызвала бы бесконечную по объёму реакцию.

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

Зато сейчас, когда Core-версия разрабатывается прилюдно, с косяками в самом языке стало полегче.

Например, последний косяк C# был в уродской декомпозии типов для целей паттерн-матчинга.
Этот ужас был разработан еще для старого фреймворка за закрытыми дверями, ничего удивительного.
Сравни теперь с той элегантностью, которую разработали уже с привлечением сообщества для тех же целей уже в Core, ы?