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

E>А на каких платформах?

На маргинальных, к счастью. Всякая встраиваемая гадость.

АТ>>>Также стоит упомянуть, что в С++ во многих контекстах выбор в пользу знаковых типов сдела на уровне языка и стандартной билиотеки. Сделан давно и навсегда. Это и 'size_t', и 'sid::vector<>:size_type' и т.п.
А>>Это не аргумент. Там тоже люди, и они могли не представлять к каким последствиям это может привести. Сдается мне что беззнаковые типы они выбрали по причине что неотрицательные числа "должны" представляться беззнаковыми числами (то что ты и говоришь) а не чтобы выгадать один бит. И тем не менее сам Бьярн использует int в циклах, к примеру, хотя если уж следовать стандарту, то он должен был бы писать unsigned.

E>Мне кажется, что в stl сделали выбор в пользу беззнаковых типов потому что итерация ими больше походит на итерацию указателями и итераторами.
Ну а размер контейнера? Размеры-то имеет смысл прибавлять или отнимать.

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

E>Здравствуйте, Кодт, Вы писали:

E>>>Например, как всё-таки вычислить корректно разность двух unsigned чисел, ессли больше может быть любое?

К>>Ты не понял!
К>>С арифметикой по модулю она справляется.
К>>А с человеческой — честно реализует undefined behavior, как и просил Максим. Или ты хочешь, чтобы UB всегда форматировало диск?

E>Да знаю я с чем и как она справляется.

E>Вот у меня есть две положительные величины. Те жа самые пять апельсинов у тебя и три у меня.
E>Я хочу уметь вычислить разность. Ну типа "на сколько у меня больше"
E>При этом я вовсе не хочу получить 0xFFFFFFFE а хочу получить -2. Правда извращённое желание?

Это и есть -2 в доп. коде

    int a = 0xFFFFFFFE;
    std::cout << a;

E>За лекбез спасибо, но
E>1) Нет никакой гарантии, что на всех машинах будет двоичный доп. код и будет 32-разрядный int.
E>2) Тот, кто программирует "просто числа", скажем производительность Васи или итерацию массива, при использовании беззнаковой арифметики всё время должен помнить обо всех этих особенностях реализации Кто-нибудь наконец ответит за ради чего?

По 1 пункту, я писал следующее:

Возьмём ваш пример с"-1" для 32-х разрядного регистра

Этот пример был для современных процессоров семейства х86 с 32-х быитным словом и представлением числа в доп. коде. К тому же разрядность регистра не так важна, в любом случае, при представлении числа "-1" в доп.двоичном коде получите все единицы. Главное здесь то, что представление знаковых чисел и беззнаковых отличается, и приведение знакового отрицательного числа к беззнаковому не даст ничего хорошоего.

По 2-му пункту: в общем-то тот, кто программирует, должен помнить, что в процессор оперирует с числами конечной точности представления, которая ограничена числом разрядов, отводимых по этот тип данных. И нужно знать особенности каждого типа данных, тем более в С++, т.к. он очень чувствителе к типам данных. Зачем открещиваться от какой-то части языка, если можно выучить это и использовать, там, где это требуется. Мне кажется не разумно использовать знаковый тип данных для тех величин, которые не должны стать отрицательными.

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


E>Мне кажется не разумно использовать знаковый тип данных для тех величин, которые не должны стать отрицательными.

Ради чего?

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

E>Это и есть -2 в доп. коде

E>

E>    int a = 0xFFFFFFFE;
E>    std::cout << a;
E>

И что с того?
Кстати то, что этот код выведет "-2" -- это UB

Но вообще мне всё равно надо не "-2 в доп. коде для регистра такой-то разрядности", а просто -2 число такое.

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

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


E>>Мне кажется не разумно использовать знаковый тип данных для тех величин, которые не должны стать отрицательными.

E>Ради чего?

А в чём, собственно, вопрос?

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

E>Но вообще мне всё равно надо не "-2 в доп. коде для регистра такой-то разрядности", а просто -2 число такое.

Ну здрасьте? "Число" — математическая абстракция. Само "число" невозможно "получить". Его даже вообразить тольком нельзя. Все "числа", котрые мы можем получить, увидеть, потрогать или, скажем, понюхать — это на самом деле не "числа", а разнообразные представления чисел. Вариантов представлений много и дополнителный код — лишь один из них. И какой-то вариант в любом случае равно придется выбирать. А "просто -2 число такое" — так не бывает.

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

E>Для людей, которым так нравится слово unsigned написанное не в комментарии к методу, а в имени типа возвращаемого значения я предлагаю поступать так:

E>

E>typedef int int_for_unsigned_values;
E>

E>И читабельно всё станет и совместимо и вообще со всех сторон прекрасно.

Совет, по своей сути примерно эквиватентный предложенному в соседнем сообщении варианту с различными типами в DEBUG и не DEBUG ("Безумью храбрых" и т.п.)

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

К>Здравствуйте, Максим2006, Вы писали:

М>>Было бы лучше иметь два разных типа — один для модульной арифметики, а второй — для беззнаковой (с UB при выходе за границы и иными правилами преобразования)

К>Модулярная арифметика может трактоваться как частный случай UB Так что unsigned замечательно справляется с обеими ролями.

Допустим, что модулярная арифметика — это частный случай UB А как насчёт других правил преобразования типа?

4.7/2 If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source
integer (modulo 2n where n is the number of bits used to represent the unsigned type). [Note: In a two’s
complement representation, this conversion is conceptual and there is no change in the bit pattern (if there
is no truncation). ]

Это даёт право на выражение "unsigned i = -1;" и любые преобразования int в unsigned
В общем, хотелось бы иметь тип (или модификатор), который обезопасил бы от подобных преобразований (о которых уже многие тут

Автор: remark
Дата: 14.11.06

говорили)

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

E>Прекрасный, надёжный способ сделать неотлаживаемую программу, которая в релизе и дебаге гарантированно ведёт себя по-разному!!!
Если код неправильный (!) — то по-разному

E>Не поделишься зачем это надо?
чтобы использовать usigned и чтобы в дебуге править все неоднозначные вырнинги..

Ш>В моём коде чаще всего используются беззнаковые переменные, чем знаковые.
А в моем наоборот. У тебя же примеры задействуют только unsigned и unsigned. А что будешь делать если будет необходимо смешать с обычным int-ом или double-ом? О чем тут народ и толкует. Например передать в какую-нибудь [библиотечную] функцию.

Ш>1) Беззнаковая арифметика имеет точно определённую семантику, в отличии от знаковой.
Ты о чем это?

Ш>2) В беззнаковой арифметике лего ловить переполнение.

Ш>

Ш>unsigned a=...;   
Ш>unsigned b=...;

Ш>a+=b;

Ш>if( a<b ) 
Ш>  { //overflow  
Ш>   ... 
Ш>  }
Ш>

Ты думаешь я аналогичный код не смогу написать для знаковых переменных? Кстати, ты проверяешь на переполнение уже после того как оно случилось. Надо бы проверять раньше, чтобы не допустить переменной принять invalid state.

Ш>3) В C/C++ размерности массивов выражаются беззнаковым типом size_t. По этой причине ипользовать для индексирования знаковые типы -- создавать потенциальные дыры.
Ну очень сложная арифметика нужна для индексирования массивов! Дай пример где реально нужны unsigned и где signed просто нельзя использовать.

Ш>4) LUT удобнее делать с беззнаковыми типами. Классический пример.
Левый пример какой-то.

Ш>

Ш>bool CharIsXXX(char c)
Ш> {
Ш>  static const bool table[256]={...};

Ш>  return table[(unsigned char)c];
Ш> }

Ш>

1) Почему бы уж саму с не объявить беззнаковой вместо того, что приводить ее позднее?
2) Если в функцию передается отрицательное с, то твой каст "выправляет" невалидное значение в валидное, и ни вызывающая функция и ни сама не вызываемая так и не узнают что произошло что-то не так. Имхо тут было бы правильнее проверить не является ли с меньше нуля, вернуть сразу ложь (или вообще изменить возвращаемый тип чтобы позволить сигнализировать об ошибке).

Вообще, Шахтер, Андрей Тарасевич и Ко, может объясните почему тогда стандартом не предусмотренны беззнаковые числа с плавающей точкой? И ни одна архитектура не поддерживает таких чисел насколько я знаю. Ведь беззнаковые числа имеют столько преимуществ над знаковыми!

Здравствуйте, Андрей Тарасевич, Вы писали:

Похоже разговор начинает заходить в бесконечную рекурсию


АТ>Значит надо не забывать делать приведение типа. Тут есть два очень важный момента, которые здесь уже упоминались.

АТ>Во-первых, приведение типа в данном случае — это не какой-то "странный каприз" спецификации языка, это преход между двумя приниципиально различными по своей природе арифметиками — обычной и модульной. Такой преход — событие настолько существенное, что делать его неявно в любом случае не стоит и, по этой причине, выполнение явного приведения типа более чем оправдано. Таких моментов в С/С++ навалом и избежать их не удастся отказом от безнаковых типов.

Вот именно, что переход между знаковой и беззнаковой арифметикой — событие существенное. Сразу возникает следующий вопрос. Коли уж нам не избежать делания этого перехода постоянно, т.к. "количество товара" — беззнаковое, а "разница между количествами товара" — знаковое, ЗАЧЕМ НАМ УСЛОЖНЯТЬ СЕБЕ ЖИЗНЬ ЭТИМИ ПОСТОЯННЫМИ ПЕРЕХОДАМИ? Которые (по твоим же словам) вещь серьёзная и требующая постоянного внимания и дополнительного кода. В конце концов нам никто не запрещает в int хранить положительные числа.

Был бы очень признателен за конкретный ответ на этот конкретный вопрос.

Сразу хотел бы ответить на 2 возможных ответа (не знаю, ответил бы ты ими или нет, неважно)
1. Беззнаковое увеличивает нам диапазон в 2 раза.
Ну и что? Если уж число действительно такое большое, что речь идёт о переполнении значения вверх, то это нам не даст ровным счётом ничего. Лишь небольшая затычка.
2. Использование беззнакого спасёт от каких-то ошибок.
Каким образом? Если уж мы будем делать проверки на переполнения перед каждым выполнением арифметического действия (очень сомнительно в реальной жизни, если используются голые примитивные типы), то тут без разницы используем мы знаковое или нет. Если мы таких проверок не делаем, то беззнаковое только ухудшит ситуацию, т.к. после выполнения какого-то длинного вычисления, мы хотя бы имеем возможность проверить, что у нас получилось отрицательное "количество" и вызвать ассёрт/исключение и т.д.


АТ>Во-вторых, в обычной арифметике в общем случае при вычитании двух N-битных чисел получается N+1-битное число. Это относится в одинаковой мере и к знаковым и к беззнаковым типам. То использование знаковых типов, которое пропагандируют тут противники беззнаковых, это в большинстве своем попытка закрыть глаза на существование этой проблемы на основании того, что работая рядом с "центром" диапазона знаковых чисел мы якобы находимся в болшей безопасности, чем работая рядом с "краем" беззнакового диапазона. Это ложная безопасность. С точки зрения достижения такой безопасности, всем следовало бы пользоваться самым большим знаковым типом ('long' или в C99 'long long') и это было бы самым "безопасным" и "защищенным от ошибок" вариантом. А все остальные типы объявим ненужными, предназначеннными для "экономии битов" в рамках разных (и, без сомнения, преждевременных) оптимизаций.

АТ>В реальности же закрывать глаза на проблему диапазона типа нельзя никогда, независимо от того знаков тип или беззнаков.

Ну не знаю.
А если речь идёт о количестве строк, введённых пользователем, или количестве водителей в полисе ОСАГО и т.д.
Нет, строго говоря, тут тоже надо проверять на переполнение за 2 млрд.
И я даже думаю, что если ты повводишь в разные программы по 5 млрд чего-либо, то ты "уронишь" много программ... но я, честно говоря, не особо виню авторов этих программ.

Ну и опять же, как ты сам сказал, что это не имеет никакого отношения к signed/unsigned.


АТ>Интерсно, кстати, наблюдать, как оппоненты беззнаковых типов приводят тут примеры ошибок в их использовании, считая что эти примеры демонстрируют недостатки беззнаковых типов

Да, нет же... ну я по крайней мере... не недостатки беззнаковых типов! А то, что при использовании их писать сложнее, надо проявлять больше внимания и т.д. Ну вот ты сам написал вверху, что переходы между арфиметиками дело серьёзное, требующее внимания. Или вот тут неоднократно приводили примеры, что сравнения чего-либо можно легко и правильно и логично записать с помощью знаковых типов и можно сложно, внимательно, с дополнительными проверками записать с помощью знаковых.

Очень хотелось бы услышать твой ответ именно с этой стороны.




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

Ты упустил ещё третью часть. Есть код, который будучи записанным со знаковыми числами работает, т.е. в нём и нет ошибок и не надо их искать, а будучи записанным с беззнаковыми числами становится с ошибками и их действительно надо искать. Например, примеры со сравнениями и вычитаниями, которые тут приводились неоднократно.



E>>>Почему странно получить 4 млрд, а -5 — нормально?
ПС>>Это не нормально, это ошибка, но в случае int-а её можно обнаружить, а в случае unsigned — нет.

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

Что за посмертный метод обнаружения? А при использовании беззнаковых чисел, если ты обнаруживаешь что будет переполнение, какие варианты? Есть какой-то «непосмертный» способ обнаружения/реакции на это?

Ну разьве не приятно написать:

void f(int i)
{
  assert(i > 0);
  // ...
}

Вместо:

// во всех 100 местах, где вызывается f()
assert(x > y)
f(x - y);

Ребят, вы уже сделайте safe_unsigned класс, который при операции вычитания возвращает int.
А на всякие неявные преобразования safe_unsigned <-> int выдавал бы компилер еррор.

И будет вам счастье.

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

E>А в чём, собственно, вопрос?

В чём состоит практическая выгода unsigned типов? Вот в чём практические потери и трудности я подробно разъяснил. А в чём таки состоит выгода --

Здравствуйте, Аноним, Вы писали:

Ш>>1) Беззнаковая арифметика имеет точно определённую семантику, в отличии от знаковой.
А>Ты о чем это?

Насколько я могу предпологать то, вот о чём:
В стандарте C++ принят следующий компромис:
1) unsigned числа должны быть такими, к каким мы все привыкли. А вот числа со знаком могут быть любыми, на усмотрение авторов аппаратуры.
Поэтому не извесно что будет если
1) в арифметике со хнаком произойдёт переполнение
2) как работает преобразование из знаковых в беззнаковые и обратно, если значение не представимо в обоих типах.
3) Что будет если ты выполнишь ряд операций с отрицательным значением (деление, взятие отатка, сдвиг и т. д.)

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

Собственно далее следует моё скромное мнение на эти обстоятельства

E>В стандарте C++ принят следующий компромис:
E>1) unsigned числа должны быть такими, к каким мы все привыкли. А вот числа со знаком могут быть любыми, на усмотрение авторов аппаратуры.
Тем не менее числа int обычно всё-таки хорошо представляют именно не очень большие целые числа, так что они, как ни странно являются более высокоуровневыми.

E>Поэтому не извесно что будет если
E>1) в арифметике со хнаком произойдёт переполнение
Ну просто нужно стараться программировать так, чтобы переполнения не происходило. В случае переполнения писать assert. Так что даже если произойдёт аппаратное исключение -- ничего грандиозно другого не случится. Миримся же мы в конце концов с анологичным поведением типа double

E>2) как работает преобразование из знаковых в беззнаковые и обратно, если значение не представимо в обоих типах.
Ну просто не надо, по возможности, пользоваться этим преобразованием.

E>3) Что будет если ты выполнишь ряд операций с отрицательным значением (деление, взятие отатка, сдвиг и т. д.)
Ну это вообще не имеет отношения к проблеме типа значения. Если вам нужно выполнить такую операцию с отрицательными числами, то в С++ это одинаково нельзя сделать не через int не через unsigned int
Всё равно прийдётся писать какой-то хитрый код.

Здравствуйте, Андрей Тарасевич, Вы писали:

АТ>Ну здрасьте? "Число" — математическая абстракция. Само "число" невозможно "получить". Его даже вообразить тольком нельзя. Все "числа", котрые мы можем получить, увидеть, потрогать или, скажем, понюхать — это на самом деле не "числа", а разнообразные представления чисел. Вариантов представлений много и дополнителный код — лишь один из них. И какой-то вариант в любом случае равно придется выбирать. А "просто -2 число такое" — так не бывает.

Ну то есть ты предлагаешь вообще все вычисления производить в unsigned?
Типа интерпритировтаь его как signed в доп. коде и радоваться? Всё равно ведь "0xFFFE" и "-2" якобы отличить нельзя?

ИМХО ты переизвратил мои извращённые желания Уважаю! Ты настоящий извращенец!

---

Что касается проблем с "воображением чисел".

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

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

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

NB>По поводу Страуструпа. Если бы все было так однозначно, то vector::size_type был бы интом.

Собственно я подумал и понял почему ни size_t, ни размер std::vector, ни его индекс не могут быть в С/С++ знаковым типом.
Это всё происходит из-за так называемой совместимости.

Действительно, никто не запрещает в C++ иметь очень большие объекты. Напимер объект размером почти со всю адресуемую память. Или vector.
Мало того, такие реализации наверняка были, когда компьютеры были слабее ZX Spectrum. Не пресоналки, а реальные такие компьютеры. Большие-пребольшие.

Так что если мы хотим сформулировать стандарт языка, который будет описывать и такие архитектуры, мы просто не можем выбрать другой тип, кроме unsigned

В некотором смысле это просто следствие того, как было принято делать компьютеры. Только и всего.

---

Теперь предлагаю посмотреть на это дело с другой стороны.
В конце концов переносимость C++ программ -- это миф.
Попробуйте написать сложную программу, которая легко переживёт перенос на платформу сильно другой разрядности. Скажем из 32-бит в 16?
Нифига у вас не выйдет. Всё равно переполнения будут вас преследовать и всякие другие проблемы.

С другйо стороны в прогамме объект "размером почти со всю память" может быть только один (если он вообще такой красивый нужен).
Так что его всё равно прийдётся при переносе докручивать ручками.

Я бы вот докручивал только если произойдёт переход на такую платформу. А заранее жизнь себе не усложнял бы

Здравствуйте, Андрей Тарасевич, Вы писали:

E>>

E>>typedef int int_for_unsigned_values;
E>>

E>>И читабельно всё станет и совместимо и вообще со всех сторон прекрасно.

АТ>Совет, по своей сути примерно эквиватентный предложенному в соседнем сообщении варианту с различными типами в DEBUG и не DEBUG ("Безумью храбрых" и т.п.)

Это ещё почему? В "безумии храбрых" предлагали намеренно сделать поведение debug и release версий очень сложно различным. При этом не очень понятно за ради чего. Например, если бы мой сотрудник так поступил, я бы поставил вопрос о преднамеренном саботаже.

А я предлагаю бороться с теми "ужасными" проблемами, которые влечёт использование signed для значений, которые не могут быть по семантике отрицательными, намного прямее. На языке С++

Казалось бы, что тут такого необычного?
Вот когда тебе нужно число с плавающей точчкой ты же пишешь что-то типа fixed_number<10>?

---

Для экипажей танковой колонны разъясняю:

Я конечно утрировал. Мне кажется что проблема вообще не стоит выеденного яйца. Но signed типы приводят в случае работы просто с небольшими целыми числами к намного более простому и надёжному коду. И, как ни стринно, более переносимому. Так что попытки использовать, по идеологическим причинам (скажем ради спорной читабельности) при работе с числами unsigned типы, я воспринимаю как преднамеренное запутывание кода.

Короче выгоды от unsigned сомнительн и спорны, проблемы с использование int для представления числа апельсинов у Буратино надуманны, ИМХО, так что надо пользоваться int и всё.
Ну а если все вокруг столь странные люди, что без специального типа не могут понять, что у Буратино не должно оказаться -8 яблок, и комментарий с assert им тоже не помогают, то можно завести int_for_unsigned_values.

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

Ну так вот и объясните мне теперь, а почему же переходить к int_for_unsigned_values не надо, а к unsigned int надо?