Objective-C: тип приведения объекта к integer_t

#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 , если мой источник (где у меня нет полномочий его изменять) является an uint32_t , я предполагаю, что больше нет смысла приводить его к NSInteger ?

2. Предложение , если в вашем исходном коде он определен как uint32_t , тогда оставьте его таким и не приводите.