其中初始是适合的int64_t? [英] Which initializer is appropriate for an int64_t?

查看:260
本文介绍了其中初始是适合的int64_t?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我喜欢我的变量初始化一些虚拟的价值,并已开始使用的int64_t uint64_t中。到目前为止,它看起来像至少有三种方式,我可以初始化的int64_t 为特定值(和为无符号相当于略有改动):

 的int64_t method_one = 0;
method_two的int64_t 0LL =;
的int64_t method_three = INT64_C(0);

我用GCC和目标OS X和Linux。我想挑选的目的是为便于携带和清晰度的方法 - 但正确性,高于一切。我是不是该得太多,还是有一个最佳或推荐最适合初始化此变量类型,对于任何特定的价值我扔它(这是它的范围内,当然)的方法吗?


解决方案

 的int64_t method_one = 0;

...是完全合理的。 C99(见如草案这里;是的,我知道这是不是最新的标准了,但是它是引入了一个 INT< N> _t 类型)说:


  • 0 的类型为 INT (§6.4.4.1第5段);

  • 除权pression的类型是的int64_t (§6.5.16第3段);

  • 右手侧的类型将被转换为所述类型的前pression的(§6.5.16.1第2段);

  • 此转换不会改变值(§6.3.1.3第1段)。

因此​​,有什么不妥,在所有的,而缺乏额外的混乱使得它初始化为0或任何东西的范围否则当最可读的选项 INT

 的int64_t method_two = 0LL;

的int64_t 不保证是相同的长长;然而,这其实应为任何工作可移植签署64位值,以及(同样 ULL 无符号64位值):很长很长(和无符号长长)应该在符合C99的实现至少有64位(§5.2.4.2.1),所以 LL (和 ULL )应该永远是初始化64位值是安全的。

 的int64_t method_three = INT64_C(0);

这无疑是对价值更好的选择,这可能是一个 INT ,因为它的前presses的意图更加明确的范围之外: INT64_C(N)将扩大到适用于任何东西 N (至少)64位的范围(见§7.18一般,特别§7.8.4.1)


在实践中,我很可能使用任何上述的,这取决于上下文。例如:

  uint64_t中计数器= 0;

(为什么要添加不必要的混乱?)

  uint64_t中some_bit = 1ULL<< 40;

1<< 40 根本行不通,除非 INT 特别宽;和 UINT64_C(1) - ;< 40 似乎不太可读性我在这里)

  uint64_t中some_mask = UINT64_C(0xFF00FF00FF00FF00);

(在这种情况下,显式调用出来的值作为64位常数似乎的更多的可读性我不是写 0xFF00FF00FF00FF00ULL

I like to initialize my variables to some "dummy" value and have started to use int64_t and uint64_t. So far, it looks like there are at least three ways I could initialize an int64_t to a particular value (and with slight changes for the unsigned equivalent):

int64_t method_one   = 0;
int64_t method_two   = 0LL;
int64_t method_three = INT64_C(0);

I use GCC and target OS X and Linux. I'd like to pick a method that aims for ease of portability and clarity — but correctness, above all. Am I overthinking this, or is there a "best" or "most recommended" approach for initializing this variable type, for any particular value I throw at it (which is within its bounds, of course)?

解决方案

int64_t method_one   = 0;

...is perfectly reasonable. C99 (see e.g. draft here; yes, I know it's not the most recent standard any more, but it's the one that introduced the int<N>_t types) says that:

  • the 0 has type int (§6.4.4.1 para.5);
  • the type of the expression is int64_t (§6.5.16 para.3);
  • the type of the right-hand side will be converted to the type of the expression (§6.5.16.1 para.2);
  • this conversion will not change the value (§6.3.1.3 para.1).

So there's nothing wrong with that at all, and the lack of additional clutter makes it the most readable of the options when initialising to 0 or anything else in the range of an int.

int64_t method_two   = 0LL;

int64_t is not guaranteed to be the same as long long; however, this should in fact work portably for any signed 64-bit value as well (and similarly ULL for unsigned 64-bit values): long long (and unsigned long long) should be at least 64 bits in a C99-compliant implementation (§5.2.4.2.1), so LL (and ULL) should always be safe for initialising 64-bit values.

int64_t method_three = INT64_C(0);

This is arguably a better option for values which may be outside the range of an int, as it expresses the intent more clearly: INT64_C(n) will expand to something appropriate for any n in (at least) a 64-bit range (see §7.18 in general, and particularly §7.8.4.1).


In practice, I might well use any of the above, depending on context. For example:

uint64_t counter = 0;

(Why add unnecessary clutter?)

uint64_t some_bit = 1ULL << 40;

(1 << 40 simply won't work unless int is unusually wide; and UINT64_C(1) << 40 seems less readable to me here.)

uint64_t some_mask = UINT64_C(0xFF00FF00FF00FF00);

(In this case, explicitly calling out the value as a 64-bit constant seems more readable to me than writing 0xFF00FF00FF00FF00ULL.)

这篇关于其中初始是适合的int64_t?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆