int64_t method_one = 0;
... вполне разумно. C99 (см., например, черновик здесь; да, я знаю, что это не самый последний стандарт, но это тот, который ввел типы int<N>_t
) говорит, что:
0
имеет тип int
(§6.4.4.1 параграф 5);
- тип выражения
int64_t
(§6.5.16 параграф 3);
- тип правой части будет преобразован в тип выражения (§6.5.16.1 параграф 2);
- это преобразование не изменит значение (§6.3.1.3 параграф 1).
Так что в этом нет ничего плохого, и отсутствие дополнительных помех делает его наиболее читаемым из вариантов при инициализации до 0 или любого другого значения в диапазоне int
.
int64_t method_two = 0LL;
int64_t
не обязательно совпадает с long long
; однако на самом деле это должно переносимо работать и для любого 64-битного значения со знаком (и аналогично ULL
для 64-битных значений без знака): long long
(и unsigned long long
) должно быть не менее 64 бит в реализации, совместимой с C99 (§5.2. 4.2.1), поэтому LL
(и ULL
) всегда должны быть безопасными для инициализации 64-битных значений.
int64_t method_three = INT64_C(0);
Возможно, это лучший вариант для значений, которые могут находиться за пределами диапазона int
, поскольку он более четко выражает намерение: INT64_C(n)
расширится до чего-то подходящего для любого n
в (по крайней мере) 64-битном диапазоне (см. §7.18 в общее и, в частности, §7.8.4.1).
На практике я вполне мог бы использовать любой из вышеперечисленных, в зависимости от контекста. Например:
uint64_t counter = 0;
(Зачем добавлять ненужный беспорядок?)
uint64_t some_bit = 1ULL << 40;
(1 << 40
просто не будет работать, если только int
не будет необычно широким; а UINT64_C(1) << 40
здесь кажется мне менее читаемым.)
uint64_t some_mask = UINT64_C(0xFF00FF00FF00FF00);
(В этом случае явный вызов значения как 64-битной константы кажется мне более читаемым, чем запись 0xFF00FF00FF00FF00ULL
.)
person
Matthew Slattery
schedule
08.11.2012