Ответ 1
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
в (по крайней мере) a 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
.)