Почему или почему не я должен использовать 'УЛ.' для определения неподписанный долго?
Eric,
Никто не мешает Вам выбрать платформу/подход, которой Вы пожелали бы. Если Вы собираетесь пойти "управляемый данными / приводимый в действие хранимой процедурой" путь, то любой ценой, пойдите для него! Особенно, если это действительно, действительно помогает Вам поставить свои приложения на спецификации и вовремя.
протест быть (обратная сторона к Вашему вопросу, который является), ВСЕ Ваши бизнес-правила должны быть на хранимых процедурах, и Ваше приложение является не чем иным как тонким клиентом.
Однако те же правила применяются, если Вы делаете свое приложение в ООП: будьте последовательны. Следуйте за принципами ООП, и , что включает объекты объекта создания представить Ваши модели предметной области.
единственное реальное правило здесь является непротиворечивостью Word . Никто не мешает Вам идти центральный DB. Никто не мешает Вам делать олдскульный структурированный (иначе, функциональный/процедурный) программы. Черт, никто не мешает никому делать код стиля КОБОЛа. НО приложение должно быть очень, очень последовательно однажды спускающийся по этому пути, если это хочет достигнуть уровня успеха.
4 ответа
void f(unsigned int x)
{
//
}
void f(int x)
{
//
}
...
f(3); // f(int x)
f(3u); // f(unsigned int x)
Это так. просто еще один инструмент на C ++; если он вам не нужен, не используйте его!
В приведенных вами примерах он не нужен. Но суффиксы часто используются в выражениях, чтобы предотвратить потерю точности. Например:
unsigned long x = 5UL * ...
Вы можете получить другой ответ, если опустите суффикс UL, скажем, если ваша система имеет 16-битные целые и 32-битные длинные.
Вот еще один пример, вдохновленный комментариями Ричарда Кордена:
unsigned long x = 1UL << 17;
Опять же, вы бы получили другой ответ, если бы у вас были 16- или 32-битные целые числа, если бы вы не использовали суффикс.
Тот же тип проблемы будет применяться с 32-битными и 64-битными целыми числами и смешиванием длинных и длинных длин в выражения.
Обычно он вам не нужен, и у любого сносного редактора будет достаточно помощи, чтобы все исправить. Однако , я использую его в C # (и вы увидите это в C ++):
- Вызов универсального метода (шаблон в C ++), где типы параметров подразумеваются, и вы хотите убедитесь, что вызовите тот, который имеет тип
unsigned long. Это случается довольно часто, в том числе недавно:
Tuple
где безULон возвращаетTupleи не будет компилироваться. - Неявные объявления переменных с использованием ключевого слова
varв C # или ключевого словаautoв C ++. Для меня это менее распространено, потому что я используюvarтолько для сокращения очень длинных объявлений, аulong- наоборот.
Полагаю, какой-то компилятор может выдать предупреждение.
Может, автор делает это, чтобы убедиться, что в коде нет предупреждений?