Почему BOOL - подписанный символ?

Question

На днях пользователь сообщил мне об ошибке в элементе панели инструментов, который был отключен, когда он должен быть включен.Код проверки (упрощенный для вашего удобства) выглядел следующим образом:

- (BOOL) validateToolbarItem: (NSToolbarItem *) toolbarItem {

    NSArray* someArray = /* arrray from somewhere*/

    return [someArray count];
}

Мне потребовалось несколько минут, чтобы понять, что -count возвращает 32-разрядное целое число без знака, в то время как BOOL является 8-разрядным знаковым символом.Так уж получилось, что в этом случае someArray содержал 768 элементов, что означало, что все младшие 8 битов были равны 0. Когда int возвращается в BOOL по возвращении, он разрешается в NO, даже если человек ожидалответ будет YES.

С тех пор я изменил свой код на return [someArray count] > 0;, но теперь мне интересно, почему BOOL действительно подписанный символ.Это действительно "лучше" в некотором роде, чем int?

Answer 1

Ответы, данные (пока), сосредоточены на том, почему BOOL не является int. Этот ответ довольно ясен: char меньше, чем int, и когда Objective-C был разработан еще в 80-х, сбрасывание нескольких байтов всегда было хорошо.

Но, похоже, ваш вопрос также звучит так: «Почему BOOL подписан, а не подписан?» Для этого мы можем посмотреть, где BOOL typedef'ed, в /usr/include/objc/objc.h:

typedef signed char     BOOL; 
// BOOL is explicitly signed so @encode(BOOL) == "c" rather than "C" 
// even if -funsigned-char is used.

Итак, есть ответ: разработчики Objective-C не хотели вводить определение BOOL в char, потому что в некоторых системах под некоторыми компиляторами (и помните, что Objective-C предшествовал ANSI C, поэтому компиляторы C отличались), char был подписан, а под некоторыми, без подписи. Проектировщики хотели, чтобы @encode(BOOL) возвращало согласованное значение для разных платформ, поэтому они включили подпись в typedef.

Но все же возникает вопрос: почему подписано, а не подписано? У меня нет однозначного ответа на это; Я предполагаю, что причина в том, что они должны были выбрать один или другой, и решили пойти с подписью. Если бы мне потребовалось дальнейшее предположение, я бы сказал, что это потому, что целые числа подписаны по умолчанию (то есть, если они не содержат спецификатор подписи).

Answer 2

Возврат к более простым временам.

Тип BOOL был создан тогда, когда процессоры естественным образом работали с 8-битными типами, редко дополняя до 16 или 32-битных.Тем не менее, памяти было мало, и переполнение 1 бита на 4 байта фактически могло бы съесть заметный кусок дополнительной памяти.

Обратите внимание, что BOOL, вероятно, предшествует _bool C ++ довольно давно (iirc-- они могут быть примерно одного возрастаКогда NeXT выбрал Objective-C, C ++ был примерно такой же популярностью.).

Answer 3

Очевидный ответ заключается в том, что он в четыре раза меньше (на типичных 32-битных и 64-битных архитектурах), а также не имеет каких-либо требований по выравниванию.

Answer 4

Bools полезны для экономии места и ограничения значения до 0 или 1. Это меньший тип по той же причине, по которой вы можете использовать плавающее число над двойным или короткое над длинным.Просто проблемы с пространством.

Вот почему было бы неплохо четко указать свое приведение, а в случае логического значения выполнить фактическое логическое сравнение между двумя одинаковыми типами, чтобы получить вместо этого действительное значение bool.усеченного значения.

Answer 5

Логическое значение требует только один бит (0 или 1), однако стандартные системы работают с байтами как наименьшей единицей. Значение bool, представленное в виде байта в 8 битах, в 4 раза меньше, чем 32-разрядное целое число, поэтому мотивация для байта превышает целое число.

Answer 6

Меньше, вот и все.