Перечисления также вводятся

В компиляторе LLVM перечислимые типы могут определить размер перечисления. Это означает, что некоторые перечислимые типы могут также иметь размер, который больше, чем Вы ожидаете. Решение, как во всех других случаях, не состоит в том, чтобы сделать предположения о размере типа данных. Вместо этого присвойте любые перечисляемые значения переменной с надлежащим типом данных.

Общие проблемы преобразования типов в касании какао

Касание какао, особенно Базовая Основа и Основа, добавляют дополнительные ситуации для поиска, потому что они предлагают способы сериализировать тип данных C или получить его в объекте Objective C.

NSInteger изменяет размер в 64-разрядном коде. NSInteger тип используется всюду по Касанию Какао; это - 32-разрядное целое число в 32-разрядное время выполнения и 64-разрядное целое число в 64-разрядное время выполнения. Таким образом, при получении информации из метода платформы, берущего NSInteger введите, используйте NSInteger введите для содержания результата.

Несмотря на то, что Вы никогда не должны делать предположение что NSInteger тип является тем же размером как int введите, вот несколько критических примеров для поиска:

• Преобразование в или от NSNumber объект.

• Кодирование и декодирование данных с помощью NSCoder класс. В частности если Вы кодируете NSInteger на 64-разрядном устройстве и позже декодируют его на 32-разрядном устройстве, метод декодирования выдает исключение, если значение превышает диапазон 32-разрядного целого числа. Можно хотеть использовать явный целый тип вместо этого (см. Использование Явные Целочисленные типы данных).

• Работа с константами, определенными в платформе как NSInteger. Особо значимый NSNotFound постоянный. В 64-разрядное время выполнения его значение больше, чем максимальный диапазон int введите, таким образом усечение его значения часто вызывает ошибки в Вашем приложении.

CGFloat изменяет размер в 64-разрядном коде. CGFloat введите изменения в 64-разрядном числе с плавающей точкой. Как с NSInteger введите, Вы не можете принять это CGFloat a float или a double. Так использование CGFloat последовательно. Перечисление 2-5 показывает пример что Основа Ядра использования для создания a CFNumber. Но код принимает это a CGFloat тот же размер как a float, который является неправильным.

  Использование перечисления 2-5 CGFloat типы последовательно

// Incorrect.

CGFloat value = 200.0;

CFNumberCreate(kCFAllocatorDefault, kCFNumberFloatType, &value);

// Correct!

CGFloat value = 200.0;

CFNumberCreate(kCFAllocatorDefault, kCFNumberCGFloatType, &value);

Правила расширения знака для C и языков C-derived

C и подобные языки используют ряд правил расширения знака определить, обработать ли главный бит в целом числе как знаковый бит, когда значение присваивается переменной большей ширины. Правила расширения знака следующие:

1. Значения без знака являются расширенным нулем (не, подписываются расширенный), когда продвинуто на больший тип.

2. Даже если получающийся тип без знака, значения со знаком всегда являются знаком, расширенным, когда продвинуто на больший тип.

3. Константы (если не изменено суффиксом, такой как 0x8L) обрабатываются как самый маленький размер, который будет содержать значение. Числа, записанные в шестнадцатеричном, могут быть обработаны компилятором как int, long, и long long типы и могут быть также signed или unsigned типы. Десятичные числа всегда обрабатываются как signed типы.

4. Сумма значения со знаком и значения без знака того же размера является значением без знака.

Перечисление 2-6 показывает пример неожиданного поведения, следующего из этих правил вместе с сопроводительным объяснением.

  Пример Расширения знака перечисления 2-6 1

int a=-2;

unsigned int b=1;

long c = a + b;

long long d=c; // to get a consistent size for printing.

printf("%lld\n", d);

Проблема: Когда этот код выполняется в 32-разрядное время выполнения, результат -1 (0xffffffff). Когда код выполняется в 64-разрядное время выполнения, результат 4294967295 (0x00000000ffffffff), который является, вероятно, не, что Вы ожидали.

Причина: Почему это происходит? Во-первых, эти два числа добавляются. Значение со знаком плюс значение без знака приводит к значению без знака (правило 4). Затем, то значение продвинуто на больший тип. Это продвижение не вызывает расширение знака.

Решение: Для решения этой проблемы совместимым способом на 32 бита бросить b к a long целое число. Этот бросок вызывает не, подписывают расширенное продвижение b к 64-разрядному типу до дополнения, таким образом вынуждая целое число со знаком быть продвинутым (способом со знаком) для соответствия. С тем изменением результатом является ожидаемый -1.

Перечисление 2-7 показывает связанный пример с сопроводительным объяснением.

  Пример Расширения знака перечисления 2-7 2

unsigned short a=1;

unsigned long b = (a << 31);

unsigned long long c=b;

printf("%llx\n", c);

Проблема: ожидаемый результат (и результат 32-разрядной исполнимой программы) 0x80000000. Результат, сгенерированный 64-разрядной исполнимой программой, однако, 0xffffffff80000000.

Причина: Почему расширяется этот знак? Во-первых, когда оператор сдвига вызывается, переменная a продвинут на переменную типа int. Поскольку все значения a short целое число может вписаться в со знаком int введите, результат этого продвижения подписывается.

Во-вторых, когда сдвиг завершился, результат был сохранен в a long целое число. Таким образом, 32-разрядное значение со знаком, представленное (a << 31) был знак, расширенный (правило 2), когда это было продвинуто на 64-разрядное значение (даже при том, что получающийся тип без знака).

Решение: Бросьте начальное значение к a long целое число до сдвига. Короткое продвинуто только один раз — на сей раз к 64-разрядному типу (по крайней мере, когда скомпилировано как 64-разрядная исполнимая программа).

Работа с битами и битовыми масками

При работе с битами и масках с 64-разрядными значениями, Вы хотите избежать получать 32-разрядные значения непреднамеренно. Вот некоторые подсказки для помощи Вам.

Не предполагайте, что тип данных имеет определенную длину. Если Вы смещаетесь через биты, сохраненные в переменной типа long целое число, используйте LONG_BIT значение для определения числа битов в a long целое число. Результат сдвига, превышающего длину переменной, является архитектурно-зависимым.

Используйте инвертированные маски в случае необходимости. Будьте осторожны при использовании битовых масок с long целые числа, потому что ширина отличается между 32-разрядными и 64-разрядными временами выполнения. Существует два способа создать маску, в зависимости от того, хотите ли Вы, чтобы маска была расширенным нулем или один расширенный:

• Если Вы хотите, чтобы значение маски содержало нули в верхних 32 битах в 64-разрядное время выполнения, обычные фотошаблоны фиксированной ширины как ожидалось, потому что это будет расширено способом без знака на 64-разрядное количество.

• Если Вы хотите, чтобы значение маски содержало в верхних битах, запишите маску как поразрядную инверсию ее инверсии, как показано в Перечислении 2-8.

Перечисление 2-8  Используя инвертированную маску для расширения знака

function_name(long value)

{

    long mask = ~0x3; // 0xfffffffc or 0xfffffffffffffffc

    return (value & mask);

}

В коде обратите внимание на то, что верхние биты в маске заполнены в 64-разрядном случае.

Используйте явные целочисленные типы данных

Стандарт C99 обеспечивает встроенные типы данных, которые, как гарантируют, будут определенным размером, независимо от архитектуры используемого оборудования. Необходимо использовать эти типы данных, когда данные должны быть фиксированным размером или когда Вы знаете, что определенная переменная имеет ограниченный диапазон возможных значений. Путем выбора надлежащего типа данных Вы получаете тип фиксированной ширины, который можно сохранить в памяти, и Вы также избегаете тратить впустую память путем выделения переменной, диапазон которой намного больше, чем Вам нужно.

Таблица 2-1 перечисляет типы C99 вместе с диапазонами позволенных значений для каждого.

Будьте Осторожны При Выравнивании 64-разрядных Целых типов

В 64-разрядное время выполнения выравнивание всех 64-разрядных целых типов изменяется с 4 байтов до 8 байтов. Даже при указании каждого целого типа явно эти две структуры все еще могут не быть идентичными в оба времени выполнения. В Перечислении 2-9 изменяется выравнивание даже при том, что поля объявляются с явными целыми типами.

  Выравнивание перечисления 2-9 64-разрядных целых чисел в структурах

struct bar {

    int32_t foo0;

    int32_t foo1;

    int32_t foo2;

    int64_t bar;

};

Когда этот код компилируется с 32-разрядным компилятором, полем bar начинает 12 байтов с запуска структуры. Когда тот же код компилируется с 64-разрядным компилятором, полем bar начинает 16 байтов с запуска структуры. Четыре байта дополнения добавляются после foo2 так, чтобы bar выровненный к 8-байтовой границе.

Если Вы определяете новую структуру данных, организуете элементы с самыми большими значениями выравнивания сначала и самые маленькие элементы в последний раз. Эта организация структуры избавляет от необходимости большинство дополнительных байтов. Если Вы работаете с существующей структурой, включающей неправильно выровненные 64-разрядные целые числа, можно использовать прагму для принуждения надлежащего выравнивания. Перечисление 2-10 показывает ту же структуру данных, но здесь структура вынуждена использовать 32-разрядные правила выравнивания.

Перечисление 2-10  Используя прагмы для управления выравниванием

#pragma pack(4)

struct bar {

    int32_t foo0;

    int32_t foo1;

    int32_t foo2;

    int64_t bar;

};

#pragma options align=reset

Используйте эту опцию только при необходимости, потому что существует потеря производительности для неправильно выровненных доступов. Например, Вы могли бы использовать эту опцию поддержать обратную совместимость со структурами данных уже в использовании в 32-разрядной версии Вашего приложения.

Всегда определяйте прототипов функции

При компиляции использования модернизированных настроек проекта компилятор генерирует ошибки, при попытке сделать вызов функции к функции, не имеющей явного прототипа. Необходимо обеспечить прототипа функции так, чтобы компилятор мог определить, является ли функция функцией variadic или нет.

Указатели функции должны использовать корректный прототип

При передаче указателя функции в коде его соглашения о вызовах должны остаться непротиворечивыми. Это должно всегда брать тот же набор параметров. Никогда не бросайте функцию variadic к функции, берущей постоянное число параметров (или наоборот). Перечисление 2-13 является примером проблематичного вызова функции части. Поскольку указатель функции был брошен для использования различного набора соглашений о вызовах, вызывающая сторона собирается поместить параметры в место, которое не ожидает вызванная функция. Это несоответствие может заставить Ваше приложение разрушать или показывать другие непредсказуемые способы поведения.

  Кастинг перечисления 2-13 между variadic и nonvariadic функционирует результаты по ошибке

int MyFunction(int a, int b, ...);

int (*action)(int, int, int) = (int (*)(int, int, int)) MyFunction;

action(1,2,3); // Error!

Сообщения Objective C отгрузки Используя прототип функции метода

Когда Вы вызываете, исключение к правилу кастинга, описанному выше, - objc_msgSend функционируйте или любые другие подобные функции во время выполнения Objective C, отправляющие сообщения. Несмотря на то, что прототип для функций сообщения имеет форму variadic, функция метода, вызванная временем выполнения Objective C, не совместно использует тот же прототип. Время выполнения Objective C непосредственно диспетчеризирует функции, реализующей метод, таким образом, соглашениям о вызовах не соответствуют, как описано ранее. Поэтому необходимо бросить objc_msgSend функционируйте к прототипу, соответствующему вызванную функцию метода.

Перечисление 2-14 показывает надлежащую форму для диспетчеризации сообщения к объекту с помощью низкоуровневых функций сообщения. В этом примере, doSomething: метод берет единственный параметр и не имеет формы variadic. Это бросает objc_msgSend функция с помощью прототипа функции метода. Обратите внимание на то, что функция метода всегда берет id переменная и селектор как его первые два параметра. После objc_msgSend функция брошена к указателю функции, вызов диспетчеризируется через тот же самый указатель функции.

Перечисление 2-14  Используя бросок для вызывания сообщения Objective C, отправляющего функции

- (int) doSomething:(int) x { ... }

- (void) doSomethingElse {

    int (*action)(id, SEL, int) = (int (*)(id, SEL, int)) objc_msgSend;

    action(self, @selector(doSomething:), 0);

}

Будьте осторожны при вызывании функций Variadic

Списки аргумента переменной (varargs) не предоставляйте информацию типа для параметров, и параметры автоматически не продвинуты на большие типы. Если необходимо различить различные входные типы данных, Вы, как ожидают, будете использовать строку формата или другой подобный механизм для предоставления той информации varargs функция. Если функция вызова правильно не предоставляет ту информацию (или если varargs функция не интерпретирует его правильно), Вы получаете неправильные результаты.

В частности если Ваш varargs функция ожидает a long целое число и Вы передаете в 32-разрядном значении, varargs функция содержит 32 бита данных и 32 бита мусора от следующего параметра (который Вы теряете в результате). Аналогично, если Ваш varargs функция ожидает int введите и Вы передаете в a long целое число, Вы получаете только половину данных, и остальное неправильно появляется в следующем параметре. (Один пример этого происходит при использовании неправильного printf строки формата.)