const long x = -6;
const unsigned long length = 2;
const long mid = (x + x + length) / 2;
signed или unsigned, вот в чем вопрос
Однажды обсуждал с одним архитектором вопрос об использовании знаковых/без знаковых типов данных.
Моя точка зрения была и пока остается такой:
Без крайней необходимости я не использую беззнаковые типы данных, т.к. это можен повлечь за собой неожиданные ошибки при вычислении выражений со смешанными типами.
Тип данных должен соответствовать смыслу самой сущности, т.е. если у нас целочисленная координата точки на оси, то тип у нее знаковый, если длина отрезка, то беззнаковый.
Такой код конечно же работать не будет. Необходимо делать преобразование к знаковому типу до деления, либо использовать знаковый тип для длины:
В своей пратике подобных ошибок я допускал может и не много, но на их поиск уходило достаточно времени и, согласитесь, такие ошибки не из приятных. Они могут проявиться не сразу, а только при определенных условиях и сразу ответить на вопросы "где" и "почему" очень сложно.
Хотелось бы узнать мнение других по этому вопросу...
Моя точка зрения была и пока остается такой:
Цитата:
Без крайней необходимости я не использую беззнаковые типы данных, т.к. это можен повлечь за собой неожиданные ошибки при вычислении выражений со смешанными типами.
У моего же оппонента точка зрения была примерно такая:
Цитата:
Тип данных должен соответствовать смыслу самой сущности, т.е. если у нас целочисленная координата точки на оси, то тип у нее знаковый, если длина отрезка, то беззнаковый.
В какой-то степени я с ним абсолютно согласен, но за эту красоту описания предметной области часто приходиться платить долгими поисками ошибок.
Например, такая задачка:
Есть отрезок. Дана координата одной его точки (x) и длина (length), надо найти координату середины отрезка.
Код:
Такой код конечно же работать не будет. Необходимо делать преобразование к знаковому типу до деления, либо использовать знаковый тип для длины:
Код:
const long x = -6;
const long length = 2;
const long mid = (x + x + length) / 2;
const long length = 2;
const long mid = (x + x + length) / 2;
В своей пратике подобных ошибок я допускал может и не много, но на их поиск уходило достаточно времени и, согласитесь, такие ошибки не из приятных. Они могут проявиться не сразу, а только при определенных условиях и сразу ответить на вопросы "где" и "почему" очень сложно.
Хотелось бы узнать мнение других по этому вопросу...
Прежде всего, надо понять, что середин отрезка две штуки, т.к. откладывать можно как в плюс, так и в минус. Далее непонятно, откуда такие сложности (x+x+length)/2. Не проще было бы так:
Вроде все ОК.
Код:
long mid1 = x + length / 2;
long mid2 = x - length / 2;
long mid2 = x - length / 2;
Вроде все ОК.
Мой подход прост - беру с запасом.
_const_
;)
P.S. Сколько будет, два плюс два деленное на два :)
Код:
long mid1 = (x + length) / 2;
long mid2 = (x - length) / 2;
long mid2 = (x - length) / 2;
;)
P.S. Сколько будет, два плюс два деленное на два :)
Цитата: _const_
Прежде всего, надо понять, что середин отрезка две штуки, т.к. откладывать можно как в плюс, так и в минус. Далее непонятно, откуда такие сложности (x+x+length)/2. Не проще было бы так:
Вроде все ОК.
Код:
long mid1 = x + length / 2;
long mid2 = x - length / 2;
long mid2 = x - length / 2;
Вроде все ОК.
Цель примера - показать ошибку, а не найти середину отрезка. Какая разница какая середина и куда откладывать?
P.S. Убедительная просьба постить по-существу, а не "здесь был Вася". Проблему я описал.
Цитата: mike
Мой подход прост - беру с запасом.
Так что такое с запасом? Если значение всегда неотрицательно, то использовать unsigned? Или это выбор размера типа данных? - что в данном топике не обсуждается...
Пример мне кажется не корректным - так как выражение со смешанным типом уже наверно стоит задуматься что пойдет что-то не так.
А вот подход вашего друга архитектора мне кажется правильным. Безусловно из правил существуют исключения, но что же теперь из за возможности подобной ошибки отказыватся от логичности определения данных? Так не долго и от const отказатся =)
А вообще как повторял за Хоаром товарищ Кнут - "Преждевременная оптимизация ..." ну а дальше знаешь.
А вот подход вашего друга архитектора мне кажется правильным. Безусловно из правил существуют исключения, но что же теперь из за возможности подобной ошибки отказыватся от логичности определения данных? Так не долго и от const отказатся =)
А вообще как повторял за Хоаром товарищ Кнут - "Преждевременная оптимизация ..." ну а дальше знаешь.
Цитата: vAC
Цель примера - показать ошибку, а не найти середину отрезка. Какая разница какая середина и куда откладывать?
P.S. Убедительная просьба постить по-существу, а не "здесь был Вася". Проблему я описал.
P.S. Убедительная просьба постить по-существу, а не "здесь был Вася". Проблему я описал.
Так об этом и речь. Чтобы избежать ошибок, надо внимательно смотреть задачу. А иначе и без unsigned можно натворить всякого.
Цитата: Odissey_
Пример мне кажется не корректным - так как выражение со смешанным типом уже наверно стоит задуматься что пойдет что-то не так.
Ну пример конечно же не правдоподобный, согласен. Но все равно, избежать выражений со смешанными типами при втором подходе будет сложно и нужно будет постоянно задумываться о возможной ошибке.
Цитата: Odissey_
А вот подход вашего друга архитектора мне кажется правильным.
Мне он тоже кажется правильным, но на практике приводящим к некоторым неудобствам (приведение типов) и ошибкам. Возможно это из-за следующего...
Цитата: Odissey_
Безусловно из правил существуют исключения, но что же теперь из за возможности подобной ошибки отказыватся от логичности определения данных? Так не долго и от const отказатся =)
Вот вы упомянули const и я вспомнил слова Дж. Элджера, примерно такие:
Цитата:
const нужно использовать либо с полной фанатичностью, либо не использовать вообще.
Может здесь и такая же проблема...
Кстати, контрпример (short вместо int использован для простоты):
В общем, по-моему самый правильный вариант - компилировать с наивысшим уровнем предупреждений. Любой нормальный компилятор при преобразовании signed/unsigned кинет warning.
Код:
int arr[50000];
for (short i = 0; i < 50000; ++i)
arr = 1; // Oops...
for (short i = 0; i < 50000; ++i)
arr = 1; // Oops...
В общем, по-моему самый правильный вариант - компилировать с наивысшим уровнем предупреждений. Любой нормальный компилятор при преобразовании signed/unsigned кинет warning.
Я предпочитаю использовать беззнаковые типы тогда, когда переменные такого типа точно не могут получить отрицательное значение, обычно это счётчики. Кроме прочего, оптимизация на выборе числового типа данных в конкретно моей практике далеко не всегда имеет сколько-нибудь заметное значение. Допустим, у меня имеется циклическое обращение к БД, и в цикле кроме обращения делается ещё много всякой работы. Если у меня по условию задачи заведомо не больше двухсот итераций цикла, я, конечно, могу использовать тип byte вместо привычного integer, я сэкономлю ещё три байта, но если где-то в цикле, скажем, создаётся новый объект, то три байта экономии не изменят решительно ничего ни в быстродействии, ни в затратах ресурсов, а формальная красота выбора правильного типа данных для счётчика в готовом продукте вообще никого не интересует. Поэтому я беззнаковые типы использую только тогда, когда знаковый использовать невозможно или очевидно неоптимально.
Цитата: vAC
Может здесь и такая же проблема...
Ну мне не кажется это проблемой, это плата за частичную сильную типизацию. Возможность игнорировать или убрать действия правил типизации дает определенную гибкость, но и требует зоркости от программиста =)
Цитата: Odissey_
Ну мне не кажется это проблемой, это плата за частичную сильную типизацию. Возможность игнорировать или убрать действия правил типизации дает определенную гибкость, но и требует зоркости от программиста =)
Использую безнаковые только в параметрах функции, чтобы предостеречь от неверного указания
Код:
GetMid(unsigned int nLength)
>Sanila_san
Я за такойже подход...
В Jave например вообще нет беззнаковых типов.
>AndreySar
GetMid((unsigned)-10);
Вцелом любой вменяемый компилятор либо подскажет вам о автоприведении типов, либо потребует явного их указания.
Я за такойже подход...
В Jave например вообще нет беззнаковых типов.
>AndreySar
GetMid((unsigned)-10);
Вцелом любой вменяемый компилятор либо подскажет вам о автоприведении типов, либо потребует явного их указания.
В своей работе использую C#.
Всегда использую int (System.Int32), если значимости не хватает - long (System.Int64).
Подобный выбор связан еще с тем, что любые побитовые операции происходят именно над этими типами (остальные типы имплицитно приводятся к ним).
Для вычислений, в которых целочисленные переполнения могут сыграть фатальную роль, стараюсь использовать конструкцию checked { }, а для конструкций, где значимость не важна или даже вредна - сложные операции с битами, счетчики с переполнениями и т.п. - использую unchecked { }.
Всегда использую int (System.Int32), если значимости не хватает - long (System.Int64).
Подобный выбор связан еще с тем, что любые побитовые операции происходят именно над этими типами (остальные типы имплицитно приводятся к ним).
Для вычислений, в которых целочисленные переполнения могут сыграть фатальную роль, стараюсь использовать конструкцию checked { }, а для конструкций, где значимость не важна или даже вредна - сложные операции с битами, счетчики с переполнениями и т.п. - использую unchecked { }.