#objective-c
#objective-c
Вопрос:
integer_t
является typedef int32_t
, как определено здесь, и после некоторой проверки integer_t
имеет размер 4 байта, как и int
(intValue), согласно упомянутому в этом документе. Мой вопрос в том, приводит ли подобное приведение к допустимому результату?
integer_t value = 100;
id anObject = @(value);
integer_t aValue = [anObject intValue];
aValue
Всегда равно value
? Вызовет ли это какие-либо проблемы в долгосрочной перспективе? Должен ли я сделать long value = [anObject longValue]
вместо этого? Заранее спасибо.
Комментарии:
1. Просто комментарий — заголовок этого сообщения немного вводит в заблуждение. Нигде вы не приводите объект к чему-либо.
Ответ №1:
Короткий и конкретный ответ — ДА, эти значения равны, поскольку integer_t
и int
оба (по вашему мнению — вот уловка) имеют одинаковый размер И одинаковую знаковость. Если бы это был, например, какой-то тип unsigned int, тогда это не сработало бы. И это не сработало бы, если бы один был, например, 8 байт (длиной), а другой 4 (int).
Длинный и общий ответ — это зависит. Да, здесь вы думаете, что оно равно, но всегда есть забавные случаи, на которые нужно обратить внимание. Я уже упоминал размер и подписанность, но реальная проблема может быть связана с архитектурой системы. Таким образом, вы можете предположить, что они одинаковы, а затем в один прекрасный день вы компилируете для 64b arch, и все ломается, так как int
длина составляет 8 байт, а все integer_t
равно равно 4. например, вы также можете столкнуться с проблемами с порядковым номером. Таким образом, если вы получаете кучу int
s из мэйнфрейма, они могут быть сохранены BADC
, где A, B, C и D — это 4 байта int .
Как вы можете видеть, легко напугать любого, кто работает с ними, и на практике именно поэтому есть такие вещи, как NSInteger
попытка Objective-C защитить вас от них. Но не пугайтесь, это беззубые монстры, если только вы не работаете на низком уровне, и тогда ваша работа будет заключаться в том, чтобы работать с ними. Разве это не звучит поэтично.
Вернемся к коду — не беспокойтесь слишком сильно об этом. Если вы работаете в Objective-C, возможно, попробуйте пока использовать NSInteger
NSUInteger
типы and . Если вы сохраняете их и вам нужно загрузить его снова позже, вам нужно подумать о возможности сохранения его из 32-битной арки и восстановления его в 64-битной арке и как-то обойти это.
Комментарии:
1. Спасибо за очень четкое объяснение. Что касается
NSInteger
, если мой источник (где у меня нет полномочий его изменять) является anuint32_t
, я предполагаю, что больше нет смысла приводить его кNSInteger
?2. Предложение , если в вашем исходном коде он определен как
uint32_t
, тогда оставьте его таким и не приводите.