长度为8的结构的效率,以及uint64_t

前端之家收集整理的这篇文章主要介绍了长度为8的结构的效率,以及uint64_t前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
TLDR:8字节结构的处理效果与8字节uint64_t一样高效吗?

我有3个非常相似的数据结构.它们长6,7和8个字节.我想把它们全部放在uint64_t变量中.目标是比较和分配将非常有效. (这些值在几个(大)树中用作键).

示例:我为7字节长的数据结构定义了以下数据结构.

typedef struct {
  union {
    uint64_t raw;
    struct {
      uint8_t unused;
      uint8_t node_number;
      uint8_t systemid[SYSTEMID_LENGTH]; /* SYSTEMID_LENGTH is 6 bytes. */
    } nodeid;
  };
} nodeid_t;

我现在可以通过原始联盟成员快速分配和复制.

nodeid_t x,y;

x.raw = y.raw
if (x.raw > y.raw) {

等等

我的问题是关于在函数和赋值中的使用.
当我按值传递此结构时,编译器(gcc)是否会识别出这些结构长度为8个字节.因此,好像他们是int64_t?

示例:以下两者之间是否存在效率/性能差异:

int64_t my_function();
nodeid_t my_function();

换句话说,gcc会使用1条指令将nodeid_t放在堆栈上,好像它是一个整数吗?或者它会创建一个循环,并逐个复制8个字节?这取决于-O优化吗?

同样的转让问题.

int64_t a,b;
nodeid_t x,y;

a = b; /* One machine instruction,I hope. */
x = y; /* Also one instruction,or will it do a loop ? */

解决方法

您无法确定联合的大小与uint64_t相同.

这是由于在nodeid结构中打包:编译器通常会在struct成员之间插入空白.有些编译器允许您更改打包安排,但您的代码将无法移植.

拥有一个uint8_t数组会更安全:那么内存将是连续的.

然后编译器将简单地复制内存,因此您也可以使用nodeid_t作为函数返回类型.

你的第二个工作是重命名nodeid_t:_t后缀在POSIX C中保留.

猜你在找的Windows相关文章