BOOL определение

Question

Всякий раз, когда тип данных BOOL не является предопределенным, я использовал логическое значение со следующим определением

typedef unsigned char BOOL;

(из-за использования памяти).

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

typedef unsigned int BOOL;

Теперь, что произойдет с 64-битным процессором, если я все еще хочу определить BOOL для собственной ширины шины.

Answer 1

Я бы не стал беспокоиться о ширине встроенной шины так, как эффективная ширина (это была ваша цель, верно)? Практически на любой машине любой приличный компилятор скомпилирует unsigned int до достаточно эффективной ширины, так что вы готовы к работе.

Answer 2

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

Кроме того, однажды вам может понадобиться массив логических значений, и в этом случае использование слова «процессор» для логического значения может не быть лучшим решением.

Answer 3

Почему бы вам не использовать тип bool в stdbool.h ?

Answer 4

size_t

Answer 5

Я бы порекомендовал использовать препроцессор.

 #ifndef BOOL 
   #ifdef ILP32
     #define BOOL uint32_t
   #endif
   #ifdef LP64
     #define BOOL uint64_t
   #endif
 #endif

Answer 6

оптимально для большинства платформ

typedef enum { ЛОЖЬ = 0, ИСТИНА = 1, } BOOL;

Answer 7

По крайней мере, x86 и ARM способны загружать и хранить байты в и из 32-битного регистра без каких-либо штрафов, так что на самом деле использование char не влияет на производительность. Я не совсем уверен, но готов поспорить, что в x86-64 тоже есть такие инструкции. (Конечно, x86 и x86-64 также могут обрабатывать 8-битные значения непосредственно в регистрах.).

Таким образом, единственное беспокойство может быть о расположении памяти. Конечно, компилятор выравнивает все, так что большую часть времени значения char в структурах дополняются, если только они не расположены рядом друг с другом, тогда вы можете сэкономить несколько байтов и получить немного лучшую производительность кэша. Если у вас есть огромные массивы BOOL, а память вызывает беспокойство, вам все равно следует их упаковать.

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

Answer 8

int_fast8_t из stdint.h - хороший выбор

Answer 9

Использование символа может быть медленнее, чем использование целого числа.

Answer 10

Ну, вы всегда можете определить typedef как long long или что-то еще, но я на самом деле не уверен, что это то, что люди делают по какой-то причине. (вы могли бы также сделать условное определение на основе sizeof (int *) или чего-то подобного).