Я действительно думаю, что лучше разделить проект также, но все это зависит от размера проекта и числа людей, работающих над ним.
Для больших проектов, у меня есть проекты для
, я получил модель от Rob Connery, и его приложение витрины..., кажется, работает действительно хорошо.
В Руководстве по стилю Google C ++ есть интересное мнение о беззнаковых целых числах:
(цитата следует:)
О беззнаковых целых
Некоторые люди, в том числе некоторые авторы учебников рекомендуют использовать типы без знака для представления чисел, которые никогда не являются отрицательными. Это задумано как форма самодокументирования. Однако в C преимущества такой документации перевешиваются реальными ошибками, которые она может внести. Учтите:
for (unsigned int i = foo.Length()-1; i >= 0; --i) ...
Этот код никогда не прекратится! Иногда gcc замечает эту ошибку и предупреждает вас, но часто этого не происходит. В равной степени плохие ошибки могут возникнуть при сравнении переменных со знаком и без знака. По сути, схема продвижения типов в C заставляет беззнаковые типы вести себя иначе, чем можно было бы ожидать.
Итак, документ, подтверждающий, что переменная неотрицательна, используя утверждения. Не используйте беззнаковый тип.
Конечно, подписано. Если вас беспокоит переполнение, недополнение должно беспокоить вас больше, потому что случайное падение «ниже нуля» легче, чем при использовании int-max.
«unsigned» должен быть осознанным выбором, который заставит разработчика задуматься о потенциальных рисках, используемых только там где вы абсолютно уверены, что у вас никогда не будет отрицательного результата (даже случайно),
В качестве примерного практического правила я использовал целые числа без знака для подсчета и подписанные целые числа для измерения.
Если вы обнаружите, что уменьшаете или вычитаете из целого числа без знака, тогда вам следует быть в контексте, где вы уже ожидаете, что будете очень осторожны, чтобы не допустить потери значимости (например, потому что вы в некотором низкоуровневом коде отступаете от конца строки, поэтому, конечно, вы сначала убедитесь, что строка достаточно долго, чтобы поддерживать это). Если вы не находитесь в таком контексте, где абсолютно важно, чтобы вы не опускались ниже нуля, тогда вам следовало использовать значение со знаком.
В моем случае целые числа без знака предназначены для значений, которые абсолютно не могут стать отрицательными. (или для той ситуации из миллиона, когда вам действительно нужна арифметика по модулю 2 ^ N),
Я сомневаюсь, что есть действительно хороший языковой независимый ответ на этот вопрос. Между языками и тем, как они обрабатывают смешанные типы, достаточно различий, поэтому ни один ответ не будет иметь смысла для всех (или даже для большинства).
В языках, которые я использую чаще всего, я использую подписанный, если у меня нет особой причины для поступай иначе. Хотя это в основном C и C ++. На другом языке я мог бы дать другой ответ.
Назначение более конкретного типа (например, unsigned int) передает больше информации об использовании переменной и может помочь компилятору отслеживать всякий раз, когда вы присваиваете "неправильное" значение. Например, если вы используете переменную для отслеживания идентификатора объекта / элемента в базе данных, то (вероятно) никогда не должно быть момента, когда идентификатор меньше нуля (или единицы); в таком случае вместо утверждения этого состояния использование целого числа без знака передает это утверждение другим разработчикам, а также компилятору.
Вы не получите особой «гарантии против переполнения» без знака. Скорее всего, у вас будет другое, но более странное поведение, чем с подписью, но немного позже ... Может быть, лучше сразу сделать эти предположения?
Я предпочитаю использовать подписанный, если только не знаю, что мне нужен unsigned, поскольку int
обычно подписан, и для ввода требуется больше усилий unsigned int
и uint
могут вызвать у другого программиста небольшую паузу, чтобы подумать о том, какими могут быть значения.
Итак, я не вижу никакой выгоды в простом использовании по умолчанию без знака, поскольку нормальное int подписано.