Нужен ли unsigned - Компьютерные священные войны

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

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

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

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

Для меня "выгоды" состоят в следущем:

1. Не вижу смысла использоваться знаковые целые для величин, которые не будут отрицательными -> дополнительная информация тому, кто будет использовать код
2. Т.к. нет отрицательных значений убирается проверка на то, что значение выскочило "ниже" положенного. То, что удобно ловить ошибки по отрицательным — не соглашусь, ошибку нужно ловить перед выполнением операции.
3. Если в коде с беззнаковой арифметикой содержится ошибка, то она очень быстро даст о себе знать, в отличие от знаковой, на которой до поры, до времени всё будет работать, а когда ошибка даст о себе знать, то тогда уже может понадобиться ни день, и не два на отладку. Вполне возможно, что всё будет работать до самого релиза. Статья на тему

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

E>Для меня "выгоды" состоят в следущем:
Спасибо за ответ!
Ты первый человек в этом обсуждении, кто решился таки понятно перечислить что нравится.
Увы, мне это всё не совсем кажется выгодами

E>1. Не вижу смысла использоваться знаковые целые для величин, которые не будут отрицательными -> дополнительная информация тому, кто будет использовать код
Это вообще не выгода

Выгода, это когда ты что-то получаешь. Я так понял, что тебе слово unsigned в имени типа ближе роднее и понятнее, чем, например, комментарий. Видимо то, что слово unsigned в С++ обозначает нечто очень своеобразное и совсем другое (модульная арифметика, тоо сё) тебе не важно.
Но почему тогда не делать как-то прямо. Например так?
Опять же, смотри. И читабельно, и модульной арифметики не надо и в debug-версии есть где assert'ы (в варианте с enum) написать.

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

Ну а что касается проверок до, а не после, то я согласен совершенно, но не понимаю чем тут unsigned типы-то помогают? Вот такой подход помог бы, да. А unsigned-то тут какой помошник?

E>3. Если в коде с беззнаковой арифметикой содержится ошибка, то она очень быстро даст о себе знать, в отличие от знаковой, на которой до поры, до времени всё будет работать, а когда ошибка даст о себе знать, то тогда уже может понадобиться ни день, и не два на отладку. Вполне возможно, что всё будет работать до самого релиза. Статья на тему

Юмор состоит в том, что вполне возможно, что будет работать и вообще до скончания веков

Я согласен, что программирование с unsigned типами тербует от программиста больше работы, выявляет больше ошибок и в результате получается тот же результат. Но вот за ради чего? почему "больше работы с тем же результатом" -- это выгода?

Вот смотри, есть два куска кода:

for( int i = count - 1; i >= 0; i-- )
    do_somthing( i );

unsigned int i = count;
while( i > 0 ) {
    i--;
    do_somthing( i );
}

Вот если бы второй был "правильным", а первый "неправильнвм", то да. Такой подхд бы был верным. Не спорю. Но ведь они оба правильные. Просто во втором проще ошибиться

Так что я не совсем понял что ты имеешь в виду под третьей выгодой

Кстати, что касется "статьи на тему", то я там слово "unsigned" нашёл только вот в таком абзаце:

Вы обязаны возвращать значение и должны передавать параметры, как указано (и вы обязаны использовать типы WPARAM и LPARAM, если вам нужна совместимость с 64-битным миром; определенное количество людей, "знавших", что WPARAM означает WORD и просто писавших (WORD, LONG) в своем коде под Win16, расплачивались при попытке перейти на Win32, где это, в действительности, (UNSIGNED LONG, LONG). И все опять будет иначе в Win64. Так зачем делать неправильно, пытаясь показаться умным?).

Вроде как тут вообще про разные версии Win API человек пишет. И тема знаковости/беззанковости и что лучше/хуже вообще не раскрыта

Тонкий намёк на выражение "для тех, кто в танке"

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

E>Тонкий намёк на выражение "для тех, кто в танке"

Ну тут есть мода давать всякие советы и разъяснения не активным участникам дискуссии, а тем, кто пытается хоть как-то въехать в обсуждаемую тему.

Мы тут жжём все конечно, но понятноможет быть и не всем.
Ну а так как народу много, то одного танка на всех однозначно не хватит

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

E>Для меня "выгоды" состоят в следущем:

E>1. Не вижу смысла использоваться знаковые целые для величин, которые не будут отрицательными -> дополнительная информация тому, кто будет использовать код

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

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

Да, с unsigned можно ловить сделанные ошибки переполнения. После операции сложения. После умножения уже никакой гарантии. Я к тому, что на мой взгляд ловля ошибок переполнения постфактум вообще нежелательна в рабочем коде.

E>3. Если в коде с беззнаковой арифметикой содержится ошибка, то она очень быстро даст о себе знать, в отличие от знаковой, на которой до поры, до времени всё будет работать, а когда ошибка даст о себе знать, то тогда уже может понадобиться ни день, и не два на отладку. Вполне возможно, что всё будет работать до самого релиза. Статья на тему Смесь знакового и беззнакового тоже может порождать странные ошибки на которые как раз и уйдёт ни день и не два на отладку. А такая смесь может возникнуть, если есть хоть одна операция вычитания.

Повторюсь. Собственно, я не против беззнаковых типов. И думаю, что никто не против из спорящих здесь. Вопрос только в том, где их уместно применять, а где нет. Я вот считаю, что для величин, участвующих в арифметических операциях их применение весьма нежелательно. Тем более для переменных, отражающих какие-то физические реалии, даже если они по замыслу неотрицательные.

Ну кому-то это кажется удобным, кому-то нет.

По поводу typedef int int_for_unsigned_values это уже перебор. Обсуждается не само слово unsigned, а тип данных и модульная арифметика. Мне кажется, что данная "шутка юмора" здесь неуместна.

Опять же тут есть такая беда, что часто число плохо ограничено сверху. Ну скажем число апельсинов. Вот я там складывал что-то вычитал, как потом написать assert, чтор всё хорошо получилось?

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

Вот смотри, есть два куска кода:

E>

E>for( int i = count - 1; i >= 0; i-- )
E>    do_somthing( i );
E>

E>и
E>

E>unsigned int i = count;
E>while( i > 0 ) {
E>    i--;
E>    do_somthing( i );
E>}
E>

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

unsigned int i = 0;

while( i < count )
 {
    ++i;
    do_somthing( i );
}

Кстатии, если не имеет значения будет ли выполнен постфиксный или префиксный инкремент (декремент), то лучше использовать префексный, т.к. не создаётся временного объекта, это связно с особенностью реализации этих операций.

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

Прошу прощения за фразу "Вот смотрю и вижу, что ты пытаешься писать код для беззнаковых чисел, как будто они знаковые, конечно такое работать не будет."

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

Ну почему же миф? Всё вполне реально. Просто не нужно в коде использовать константы, указывающие размеры типов данных, всё определять через sizeof, а сами типы данных привести в соответствие с размером слова целевой платформы, т.е. int — 16 бит, и т.д.

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

E>По поводу typedef int int_for_unsigned_values это уже перебор. Обсуждается не само слово unsigned, а тип данных и модульная арифметика. Мне кажется, что данная "шутка юмора" здесь неуместна.
E>

E>Опять же тут есть такая беда, что часто число плохо ограничено сверху. Ну скажем число апельсинов. Вот я там складывал что-то вычитал, как потом написать assert, чтор всё хорошо получилось?

E>Очень просто, если при сложении получилось число меньшее, чем каждое из слагаемых — переполнение, аналогично для вычитатния — если результат больше, чем числа, учавствовавшие в вычитании — переполнение.

Ну тогда лучше завести enum int_for_unsigned_values и переопределить для него операции, с проверками. Разве это не более прямой и надёжный способ?

E>Вот смотри, есть два куска кода:

E>>

E>>for( int i = count - 1; i >= 0; i-- )
E>>    do_somthing( i );
E>>

E>>и
E>>

E>>unsigned int i = count;
E>>while( i > 0 ) {
E>>    i--;
E>>    do_somthing( i );
E>>}
E>>

E>unsigned int i = 0;

E>while( i < count )
E> {
E>    ++i;
E>    do_somthing( i );
E>}
E>

1) Твой код не эквивалентен моему

У меня массив итерируется с конца в начало! А вдруг мне надо именно так?
Вот при знаковом i всё равно куда и с каким шагом итерировать, а вот с unsigned начинаются косяки и двери

E>Кстатии, если не имеет значения будет ли выполнен постфиксный или префиксный инкремент (декремент), то лучше использовать префексный, т.к. не создаётся временного объекта, это связно с особенностью реализации этих операций.
Кстати, любой совсременный вменяемый компилятор скомпилирует и для int i и для unsigned int i обе формы инкремента в один и тот же код

E>По поводу статьи , я просто хотел сказать, что то, что работало на дебаге, может разчъехаться на релизе, тем более, если код с ошибкой, которая пока проезжает.

Ну так объясни какая же ошибка, которая может вылезти на релизе содердится в коде с signed i?

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

E>

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

E>Ну почему же миф? Всё вполне реально. Просто не нужно в коде использовать константы, указывающие размеры типов данных, всё определять через sizeof, а сами типы данных привести в соответствие с размером слова целевой платформы, т.е. int — 16 бит, и т.д.

У месье есть опыт или это теоритическое изыскание?

Вот представь себе, что ты пишешь текстовый редактор. Который редактирует текст на диске.
И используешь int (или даже unsigned int) для номера строки.

Ну и вот на 32-битной платформе всё у тебя будет хорошо, а вот на 16-битной уже веселее всё станет, потому что реально встретить файл на 100 000 строк

А вот на 8-битной или на 12-битной платформе вообще туго прийдётся.

Или у месье таки есть опыт?

Вот мой опыт говорит о том, что какую кросплатформенную разработку не возьмёшь, там всюду ifdef на ifdefe сидит и им же погоняет

К чему бы это, если всё так мегапереносимо?

Для сравнения советую посмотреть прогу какую-нибудь на фортране, например

Джони!
Если ты не согласен с тем, что беззнаковый size_t -- это неизбежное следствие совместимсти с подобными платформами, то поделись аргументами!
Правда очень интересно

E>Вот представь себе, что ты пишешь текстовый редактор. Который редактирует текст на диске.
E>И используешь int (или даже unsigned int) для номера строки.

E>Ну и вот на 32-битной платформе всё у тебя будет хорошо, а вот на 16-битной уже веселее всё станет, потому что реально встретить файл на 100 000 строк

E>А вот на 8-битной или на 12-битной платформе вообще туго прийдётся.

E>Или у месье таки есть опыт?

E>Вот мой опыт говорит о том, что какую кросплатформенную разработку не возьмёшь, там всюду ifdef на ifdefe сидит и им же погоняет

E>К чему бы это, если всё так мегапереносимо?

E>Для сравнения советую посмотреть прогу какую-нибудь на фортране, например

Я лично такие проекты не писал, однако у нас в городе Севастополе есть предприятие, "Таврида Электрик", которое программирует микроконтроллеры, в том числе и на С++. И ничего, живут программы. Естественно, проект требуется подредактировать. Однако, это не так страшно, как кажется. Все используемы типы данных определяются через typedef, а все платформенно-зависимые константы макросами. После корректировки этих величин под целевую платформу, получаем живущий проект.

>Ну и вот на 32-битной платформе всё у тебя будет хорошо, а вот на 16-битной уже веселее всё станет, потому что реально встретить файл на 100 000 строк

А что мешает ввести проверку? Вводишь условие, что в файле должно быть не больше UINT_MAX строк (или INT_MAX). Для 32-битной платформы это будет 2^32 -1, а для 16-ти битной 2^16-1.

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

E>А что мешает ввести проверку? Вводишь условие, что в файле должно быть не больше UINT_MAX строк (или INT_MAX). Для 32-битной платформы это будет 2^32 -1, а для 16-ти битной 2^16-1.

Ну провалится твоя проверка. И что дальше?

Всё равно прийдётся переписывать

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

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

так что с практической точки зрения совместимость такого рода ИМХО никакой ценности не имеет

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

E>Джони!
E>Если ты не согласен с тем, что беззнаковый size_t -- это неизбежное следствие совместимсти с подобными платформами, то поделись аргументами!
E>Правда очень интересно

Просто не хотел явно вмешиваться в ваш разговор. -1 это за переносимость. Люди спокойно работают пишут портируемый код (используя int32_t, uint32_t) а вы вдруг заявили что бах! нет этого кода. И люди, целые компании, растворяются в воздухе..

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

К сожалению вашей мыслью о связи size_t и слабых платформ не проникся, потому что ничего не понял.

А по поводу топика..

неявное приведение int <-> unsigned — ошибка
результат -var (где var — unsigned) не представим в unsigned, поэтому и результат var1-var2 (оба unsigned) так же в общем случае не представим в unsigned. Следовательно унарный '-' должен быть запрещён, а..
разница двух unsigned должна быть int (как сделано с указателями)

при избегании подобного рода ошибок, использование unsigned оправдано в тех случаях, когда вы декларируете что значение переменной ни при каких обстоятельствах не может быть меньше нуля — вам не придётся проверять это дополнительно. Так сделано в STL для size() — это спорно, но, как я ранее в этой ветке писал, я понял что удобно проверять индекс например вот так

if( (size_t)i < var.size() ) ... //значит мы можем использовать var[i]

Конечно, если я могу переобъявить переменную, я объявлю её size_t

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

E>Вообще языки высокого уровня

C/C++ относятся к языкам низкого уровня. Дальше — asm

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

J>Просто не хотел явно вмешиваться в ваш разговор. -1 это за переносимость. Люди спокойно работают пишут портируемый код (используя int32_t, uint32_t) а вы вдруг заявили что бах! нет этого кода. И люди, целые компании, растворяются в воздухе..

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

Обращаю твоё внимание, что ни int32_t ни uint32_t в стандарте вроде как нет

Кроме того, я вовсе не говорил, что на C++ невозможно написать переносимый и кросплатформенный код. Я говорил совсем о другом.
Что переносимость, как это понимается в стандарте, недостижима. Ну то есть чтобы вот взяли, написали и везеде работает.
Это только в довольно простых программах бывает. А в непростых и архитектуру учесть ради производительности приходится и разрядность платформы и возможности системы по работе с памятью и много чего ещё. Так что какую большую прогу не возьми -- толпы ifdef насованы, ради каждой платформы.

Ещё раз призываю сравнить с FORTRAN, например.

J>К сожалению вашей мыслью о связи size_t и слабых платформ не проникся, потому что ничего не понял.

Ну вот смотри.
Пусть у нас какой-то 16-битный компик. Скажем типа БК-0010, кажется так его звали. Только ROM мало, а RAM много. Скажем 4 против 60 килобайт. И мы можем завести объект размером в 40 кило скажем. Как его размер представлялся бы в signed int? Так что куда не денешься -- а приходится брать unsigned тип для size_t и для размера вектора.

С другой стороны если ты попробуешь перенести какую-то прогу тех самых контор, с int32_t на такой компик, то ты много-много гемора огребёшь!
Так что никакого реального выигрыша от того, что size_t "переносим" в смысле стандарта C++ при реальном переносе получить не удаётся.

неявное приведение int <-> unsigned — ошибка
Согласен. плохо то, что С++ так устроен, что при использовании вычитаения с участием unsigned типов это легко прозевать.
Мало того, явное -- тоже не особо хорошо

результат -var (где var — unsigned) не представим в unsigned, поэтому и результат var1-var2 (оба unsigned) так же в общем случае не представим в unsigned. Следовательно унарный '-' должен быть запрещён, а..
J>

разница двух unsigned должна быть int (как сделано с указателями)
Моё ИМХО проще -- если ты можешь себе представить, что может где-то рядом с твоей виличиной возникнуть "-", в смысле вычитания чисел (а не вычитания в арифметике по модулю такому-то, то не надо использовать для этой величины unsigned типы
J>

J>при избегании подобного рода ошибок, использование unsigned оправдано в тех случаях, когда вы декларируете что значение переменной ни при каких обстоятельствах не может быть меньше нуля — вам не придётся проверять это дополнительно. Так сделано в STL для size() — это спорно, но, как я ранее в этой ветке писал, я понял что удобно проверять индекс например вот так
J>

J>if( (size_t)i < var.size() ) ... //значит мы можем использовать var[i]
J>

1) если i таки может быть < 0, то этот код вообще UB. О какой вообще переносимости тут речь?

J>Конечно, если я могу переобъявить переменную, я объявлю её size_t
Ну и будет неудобно. Так как индекс в массиве легко может участвовать в вычитании. Например при итерации массива с конца в начало.

J>Благо, хороший компилятор, понимая актуальность подобных проблем, выдаёт много разных warning-ов и, в runtime, анализирует представимость результата при неявных преобразованиях типа.

И что происходит дальше? Авост?

На кой себе так переусложнять жизнь?

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

E>>Вообще языки высокого уровня
J>C/C++ относятся к языкам низкого уровня. Дальше — asm
Это очень сложный терминологический вопрос.

ИМХО во многих задачах С++ можно использовать как язык выского уровня, а можно как низкого.
Всё зависит от инструкции кодировщика/проэктировщика

Собственно моё ИМХО состоит в том, что использоание unsigned типов для индексации массива -- шаг в сторону низкого уровня, а signed -- в сторону высокого.
Ну а куда идти -- вопрос вкуса и целей

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

E>>Вообще языки высокого уровня

J>C/C++ относятся к языкам низкого уровня. Дальше — asm
аппаратноориентированные, кажись

... << Сила ночи, сила дня — одинакова х..ня!>>

E>Пусть у нас какой-то 16-битный компик. Скажем типа БК-0010, кажется так его звали. Только ROM мало, а RAM много. Скажем 4 против 60 килобайт. И мы можем завести объект размером в 40 кило скажем. Как его размер представлялся бы в signed int? Так что куда не денешься -- а приходится брать unsigned тип для size_t и для размера вектора.

Верно.

E>С другой стороны если ты попробуешь перенести какую-то прогу тех самых контор, с int32_t на такой компик, то ты много-много гемора огребёшь!
E>Так что никакого реального выигрыша от того, что size_t "переносим" в смысле стандарта C++ при реальном переносе получить не удаётся.

А тут не верно. int32_t он на то и 32 что на всех платформах 32х битный целочисленный и переносимость будет 100%.
Конечно если на 16 битной машине нет 32х битных чисел вообще, то реализовать такой тип — придётся потрудиться. Главная цель — портируемость.

Конечно, я согласен, что применять "чистые" типы себе дороже, благо все стандартные библиотеки предоставляют свой набор intxx, unsignedxx типов (можно даже без макросов, просто подключив config.h) так что этой проблемы как бы не существует.

E>Собственно моё ИМХО состоит в том, что использоание unsigned типов для индексации массива -- шаг в сторону низкого уровня, а signed -- в сторону высокого.

Моё ИМХО: выбор signed/unsigned типа — решение проектировщика — это, я понимаю, высокий (абстрактный) уровень. Тут не учитываются детали имплементации а только декларируется соглашение API о принимаемых/возвращаемых значениях. В данном случае вы предоставляете "барьер", человек, предоставляющий unsigned значение должен удостовериться что он предоставляет его правильно, соответственно API может быть спокойна за знаковость значения и наоборот.

А неумение программиста работать с unsigned типом и вообще пренебрежение низкоуровневыми деталями, которые предоставляет язык — это уже совсем другая проблема и лечиться она повышением квалификации програмиста, повышением уровня warning-ов + концепция warning -> error, административными методами. В крайнем случае, можно сменить язык на более высокоуровневый, например на ваш FORTRAN.

	От:	Erlond
	Дата:	18.11.06 09:24
	Оценка:	6 (1) +1

	От:	Erop
	Дата:	18.11.06 09:51
	Оценка:

	От:	Erlond
	Дата:	18.11.06 09:56
	Оценка:

	От:	Erop
	Дата:	18.11.06 09:59
	Оценка:

	От:	Michael7
	Дата:	18.11.06 10:36
	Оценка:	+2

От:	johny5	https://www.facebook.com/TachyonWars/
Дата:	22.11.06 16:01
Оценка:

	От:	MaximE
	Дата:	23.11.06 11:16
	Оценка: