Сообщение Re[25]: Carbon от 19.04.2024 17:52
Изменено 19.04.2024 17:53 vdimas
Re[25]: Carbon
Здравствуйте, Sinclair, Вы писали:
V>>Знаковые целые нужны редко, в основном для оперирования сущностями, близкому по смыслу к "разница", "текущий остаток/баланс", или для традиционного возврата кодов или признаков ошибок.
S>Угу. Вся индустрия идёт не в ногу, только vdimas идёт в ногу.
Мы уже обсуждали это не раз, и ты как раз отвечаешь на суть того, с чем все (или почти все) согласились — "разница" должна быть знаковой.
Например, смещение от некоего адреса — это и есть "разница".
И в языке это явно поддерживается для адресной арифметики, т.к. адреса можно складывать с положительными и отрицательными числами.
Т.е. "индекс" при указателе запросто может быть знаковым числом.
У итераторов прямого доступа тоже есть арифметика со знаковыми целыми, тут они повторяют семантику указателей.
К сожалению, в языке нет типа, который вёл бы себя как указатели — т.е. был бы беззнаковым, но допускал арифметику со знаковыми числами.
А без этого, правильно там написано по ссылке:
С другой стороны, это всё еще познаётся в бытность студентом, поэтому, или сейчас студенты хуже пошли, или стало больше людей с непрофильным образованием стало, что этот вопрос свообще поднимается.
Я ж показал рядом, как можно корректно расписать взаимодействие знаковых и беззнаковых чисел:
https://www.rsdn.org/forum/flame.comp/8734308.1
Тебе заранее на всё ответили. ))
V>>У меня обсуждаемая проблема вечно вылазит в дотнете, бо системное АПИ расписано на знаковых, даже где это выглядит абсурдом.
S>Обсуждаемая проблема в дотнете вылезти не может, т.к. в нём знаковое переполнение не является UB.
Это до тех пор, пока нет приличного оптимизатора.
А когда появится, то будет что-то типа такого поведения под x64:
бгг...
V>>Причина известна — не во всех языках есть беззнаковый тип, поэтому платформа затачивалась на слабое звено. ))
S>Опять смелая догадка.
Это официальная причина от непосредственных разработчиков дотнета.
V>>Переполнения принято производить с беззнаковыми, а со знаковыми принято оперировать так, чтобы переполнения не возникало.
S>Не, просто 99% С++ программистов вообще не в курсе, что знаковое переполнение — это UB.
Продолжаешь себя топить.
Извини, но выдать такое мог только человек с не очень большим опытом в написании программ.
А теперь правильный ответ:
Знаковое переполнения в 99.9% случаев указывает на потерю результата, т.е. на ошибку программы.
Поэтому, важность детерминированного поведения в случае знакового переполнения примерно нулевая.
Да всем насрать, собсно.
Я даже не могу придумать реальной задачи, которую стоит решать таким образом, потому что в таких задачах всегда удобней беззнаковое, т.е. просто набор бит.
И ты тоже не придумаешь такой задачи, просто разводишь своё обычное пустопорожнее ля-ля-ля.
S>Большинство пребывают примерно в таком же заблуждении, как и вы — что это Implementation-defined.
Опять чухню несмёшь какую-то.
Большинство считают переполнение знакового ошибкой программы.
Да какой большинство, хосподя... Практически все более-менее опытные программисты.
Ты бы хоть голову включил бы разок — стандарты C++ на сегодня принимаются наиболее тщательно и с самым широким обсуждением.
В обсуждении каждой мелочи (пусть чаще в режиме read-only, т.е. "контроль происходящего глазами") участвуют даже не десятки тысяч людей по всему миру, а сотни тыщ.
Любая непродуманная дичь вызвала бы бесконечную по объёму реакцию.
А ваш дотнет в первой версии, основные его концепции были разработаны тремя чуваками всего.
И как теперь избавиться от ужасных дотнетных делегатов с их уникальными типами — одному богу известно.
Тут несравнимое качество проектирования, конечно.
Тем забавнее выглядят твои трепыхания.
Зато сейчас, когда Core-версия разрабатывается прилюдно, с косяками в самом языке стало полегче.
Например, последний косяк C# был в уродской декомпозии типов для целей паттерн-матчинга.
Этот ужас был разработан еще для старого фреймворка за закрытыми дверями, ничего удивительного.
Сравни теперь с той элегантностью, которую разработали уже с привлечением сообщества для тех же целей уже в Core, ы?
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, ы?
Re[25]: Carbon
Здравствуйте, Sinclair, Вы писали:
V>>Знаковые целые нужны редко, в основном для оперирования сущностями, близкому по смыслу к "разница", "текущий остаток/баланс", или для традиционного возврата кодов или признаков ошибок.
S>Угу. Вся индустрия идёт не в ногу, только vdimas идёт в ногу.
Мы уже обсуждали это не раз, и ты как раз отвечаешь на суть того, с чем все (или почти все) согласились — "разница" должна быть знаковой.
Например, смещение от некоего адреса — это и есть "разница".
И в языке это явно поддерживается для адресной арифметики, т.к. адреса можно складывать с положительными и отрицательными числами.
Т.е. "индекс" при указателе запросто может быть знаковым числом.
У итераторов прямого доступа тоже есть арифметика со знаковыми целыми, тут они повторяют семантику указателей.
К сожалению, в языке нет типа, который вёл бы себя как указатели — т.е. был бы беззнаковым, но допускал арифметику со знаковыми числами.
А без этого, правильно там написано по ссылке:
С другой стороны, это всё еще познаётся в бытность студентом, поэтому, или сейчас студенты хуже пошли, или стало больше людей с непрофильным образованием, что этот вопрос свообще поднимается.
Я ж показал рядом, как можно корректно расписать взаимодействие знаковых и беззнаковых чисел:
https://www.rsdn.org/forum/flame.comp/8734308.1
Тебе заранее на всё ответили. ))
V>>У меня обсуждаемая проблема вечно вылазит в дотнете, бо системное АПИ расписано на знаковых, даже где это выглядит абсурдом.
S>Обсуждаемая проблема в дотнете вылезти не может, т.к. в нём знаковое переполнение не является UB.
Это до тех пор, пока нет приличного оптимизатора.
А когда появится, то будет что-то типа такого поведения под x64:
бгг...
V>>Причина известна — не во всех языках есть беззнаковый тип, поэтому платформа затачивалась на слабое звено. ))
S>Опять смелая догадка.
Это официальная причина от непосредственных разработчиков дотнета.
V>>Переполнения принято производить с беззнаковыми, а со знаковыми принято оперировать так, чтобы переполнения не возникало.
S>Не, просто 99% С++ программистов вообще не в курсе, что знаковое переполнение — это UB.
Продолжаешь себя топить.
Извини, но выдать такое мог только человек с не очень большим опытом в написании программ.
А теперь правильный ответ:
Знаковое переполнения в 99.9% случаев указывает на потерю результата, т.е. на ошибку программы.
Поэтому, важность детерминированного поведения в случае знакового переполнения примерно нулевая.
Да всем насрать, собсно.
Я даже не могу придумать реальной задачи, которую стоит решать таким образом, потому что в таких задачах всегда удобней беззнаковое, т.е. просто набор бит.
И ты тоже не придумаешь такой задачи, просто разводишь своё обычное пустопорожнее ля-ля-ля.
S>Большинство пребывают примерно в таком же заблуждении, как и вы — что это Implementation-defined.
Опять чухню несмёшь какую-то.
Большинство считают переполнение знакового ошибкой программы.
Да какой большинство, хосподя... Практически все более-менее опытные программисты.
Ты бы хоть голову включил бы разок — стандарты C++ на сегодня принимаются наиболее тщательно и с самым широким обсуждением.
В обсуждении каждой мелочи (пусть чаще в режиме read-only, т.е. "контроль происходящего глазами") участвуют даже не десятки тысяч людей по всему миру, а сотни тыщ.
Любая непродуманная дичь вызвала бы бесконечную по объёму реакцию.
А ваш дотнет в первой версии, основные его концепции были разработаны тремя чуваками всего.
И как теперь избавиться от ужасных дотнетных делегатов с их уникальными типами — одному богу известно.
Тут несравнимое качество проектирования, конечно.
Тем забавнее выглядят твои трепыхания.
Зато сейчас, когда Core-версия разрабатывается прилюдно, с косяками в самом языке стало полегче.
Например, последний косяк C# был в уродской декомпозии типов для целей паттерн-матчинга.
Этот ужас был разработан еще для старого фреймворка за закрытыми дверями, ничего удивительного.
Сравни теперь с той элегантностью, которую разработали уже с привлечением сообщества для тех же целей уже в Core, ы?
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, ы?