blocks|key|2692474|text|来自C%2B%2B14标准(N3797草案)，第9.6节class.bit，第1段：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2692475|类对象中位字段的|2692476|分配是由实现定义的。位字段的对齐是由实现定义的。位字段被打包到一些可寻址的分配单元中。注意:在一些机器上，位域跨越分配单元，而在另一些机器上则不是。位域在一些机器上是从右到左分配的，在另一些机器上是从左到右分配的。-结束注释|blockquote|2692477|2692478|2692479|尽管notes是非标准化的，但我所知道的每个实现都使用两种布局中的一种:大端或小端位顺序。|2692480|请注意：|2692481|填充您必须手动指定填充。这意味着你必须知道你的类型的大小(例如，通过使用<cstdint>).|offset|length|style|CODE|2692482|You必须使用无符号类型。用于检测位顺序的预处理器宏是implementation-dependent.|unordered-list-item|2692483|Usually+|2692484|位顺序字节序与字节顺序字节序相同。我相信有一个编译器标志可以覆盖它，但是我找不到它。|2692485|2692486|例如，查看netinet/tcp.h和其他附近的标头。|2692487|由OP编辑:例如，tcp.h定义|2692488|struct
{
++++u_int16_t+th_sport;+++++/*+source+port+*/
++++u_int16_t+th_dport;+++++/*+destination+port+*/
++++tcp_seq+th_seq;+++++/*+sequence+number+*/
++++tcp_seq+th_ack;+++++/*+acknowledgement+number+*/
#+if+__BYTE_ORDER+==+__LITTLE_ENDIAN
++++u_int8_t+th_x2:4;+++++++/*+(unused)+*/
++++u_int8_t+th_off:4;++++++/*+data+offset+*/
#+endif
#+if+__BYTE_ORDER+==+__BIG_ENDIAN
++++u_int8_t+th_off:4;++++++/*+data+offset+*/
++++u_int8_t+th_x2:4;+++++++/*+(unused)+*/
#+endif
++++//+...
}|code-block|syntax|javascript|2692489|由于它可以与主流编译器协同工作，这意味着位集的内存布局在实践中是可靠的。|2692490|编辑：|2692491|这在一个字节顺序中是可移植的：|2692492|struct+Foo+{
++++uint16_t+x:+10;
++++uint16_t+y:+6;
};|2692493|但这可能不是因为它跨越了一个16位单元：|2692494|struct+Foo+{
++++uint16_t+x:+10;
++++uint16_t+y:+12;
++++uint16_t+z:+10;
};|2692495|这可能不是因为它有隐式填充：|2692496|struct+Foo+{
++++uint16_t+x:+10;
};|2692497|entityMap^0|0|0|0|0|0|0|0|10|9|0|0|0|0|0|5|D|0|9|5|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1S|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1T|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|1W|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1X|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1Y|8|@$O|1Z|P|20|Q|R]]|9|@]|A|$]]|$1|S|3|T|5|U|7|21|8|@]|9|@]|A|$]]|$1|V|3|W|5|U|7|22|8|@]|9|@]|A|$]]|$1|X|3|Y|5|U|7|23|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|24|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|25|8|@$O|26|P|27|Q|R]]|9|@]|A|$]]|$1|12|3|13|5|6|7|28|8|@$O|29|P|2A|Q|R]]|9|@]|A|$]]|$1|14|3|15|5|16|7|2B|8|@]|9|@]|A|$17|18]]|$1|19|3|1A|5|6|7|2C|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|6|7|2D|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|6|7|2E|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|16|7|2F|8|@]|9|@]|A|$17|18]]|$1|1H|3|1I|5|6|7|2G|8|@]|9|@]|A|$]]|$1|1J|3|1K|5|16|7|2H|8|@]|9|@]|A|$17|18]]|$1|1L|3|1M|5|6|7|2I|8|@]|9|@]|A|$]]|$1|1N|3|1O|5|16|7|2J|8|@]|9|@]|A|$17|18]]|$1|1P|3|-4|5|6|7|2K|8|@]|9|@]|A|$]]]|1Q|$]]

From the C++14 standard (N3797 draft), section 9.6 [class.bit], paragraph 1:

<blockquote>
 Allocation of bit-fields within a class object is implementation-defined.
 Alignment of bit-fields is implementation-defined. Bit-fields are packed into some addressable allocation unit.
 [ Note: Bit-fields straddle allocation units on some machines and not on others. Bit-fields are assigned right-to-left on some machines, left-to-right on others. — end note ]
</blockquote>

Although notes are non-normative, every implementation I'm aware of uses one of two layouts: either big-endian or little endian bit order.

Note that:

<ul>
<li>You must specify padding manually. This implies that you must know the size of your types (e.g. by using <code>&lt;cstdint&gt;</code>).</li>
<li>You must use unsigned types.</li>
<li>The preprocessor macros for detecting the bit order are implementation-dependent.</li>
<li>Usually the bit order endianness is the same as the byte order endianness. I believe there is a compiler flag to override it, though, but I can't find it.</li>
</ul>

For examples, look in <code>netinet/tcp.h</code> and other nearby headers.

Edit by OP: for example <code>tcp.h</code> defines

<pre><code>struct
{
 u_int16_t th_sport; /* source port */
 u_int16_t th_dport; /* destination port */
 tcp_seq th_seq; /* sequence number */
 tcp_seq th_ack; /* acknowledgement number */
# if __BYTE_ORDER == __LITTLE_ENDIAN
 u_int8_t th_x2:4; /* (unused) */
 u_int8_t th_off:4; /* data offset */
# endif
# if __BYTE_ORDER == __BIG_ENDIAN
 u_int8_t th_off:4; /* data offset */
 u_int8_t th_x2:4; /* (unused) */
# endif
 // ...
}
</code></pre>

And since it works with mainstream compilers, it means bitset's memory layout is reliable in practice.

Edit:

This is portable within one endianness:

<pre><code>struct Foo {
 uint16_t x: 10;
 uint16_t y: 6;
};
</code></pre>

But this may not be because it straddles a 16-bit unit:

<pre><code>struct Foo {
 uint16_t x: 10;
 uint16_t y: 12;
 uint16_t z: 10;
};
</code></pre>

And this may not be because it has implicit padding:

<pre><code>struct Foo {
 uint16_t x: 10;
};
</code></pre>

blocks|key|2692600|text|使用C%2B%2B实现具有已知位置的位域非常简单：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2692601|template<typename+T,+int+POS,+int+SIZE>
struct+BitField+{
++++T+*data;

++++BitField(T+*data)+:+data(data)+{}

++++operator+int()+const+{
++++++++return+((*data)+>>+POS)+&+((1ULL+<<+SIZE)-1);
++++}

++++BitField&+operator=(int+x)+{
++++++++T+mask(+((1ULL+<<+SIZE)-1)+<<+POS+);
++++++++*data+=+(*data+&+~mask)+%7C+((x+<<+POS)+&+mask);
++++++++return+*this;
++++}
};|code-block|syntax|javascript|2692602|例如，上面的玩具实现允许在unsigned+long+long变量中定义一个12位字段|offset|length|style|CODE|2692603|unsigned+long+long+var;

BitField<unsigned+long+long,+7,+12>+muxno(&var);|2692604|而生成的访问字段值的代码只是|2692605|0000000000000020+<_Z6getMuxv>:
++20:+++48+8b+05+00+00+00+00++++mov++++0x0(%25rip),%25rax++;+Get+&var
++27:+++48+8b+00++++++++++++++++mov++++(%25rax),%25rax+++++;+Get+content
++2a:+++48+c1+e8+07+++++++++++++shr++++$0x7,%25rax+++++++;+>>+7
++2e:+++25+ff+0f+00+00++++++++++and++++$0xfff,%25eax+++++;+keep+12+bits
++33:+++c3++++++++++++++++++++++retq+++|2692606|基本上你必须手写的东西|2692607|entityMap^0|0|0|D|I|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Y|8|@$I|Z|J|10|K|L]]|9|@]|A|$]]|$1|M|3|N|5|D|7|11|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|12|8|@]|9|@]|A|$]]|$1|Q|3|R|5|D|7|13|8|@]|9|@]|A|$E|F]]|$1|S|3|T|5|6|7|14|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

It's simple to implement bit fields with known positions with C++:

<pre><code>template&lt;typename T, int POS, int SIZE&gt;
struct BitField {
 T *data;

 BitField(T *data) : data(data) {}

 operator int() const {
 return ((*data) &gt;&gt; POS) &amp; ((1ULL &lt;&lt; SIZE)-1);
 }

 BitField&amp; operator=(int x) {
 T mask( ((1ULL &lt;&lt; SIZE)-1) &lt;&lt; POS );
 *data = (*data &amp; ~mask) | ((x &lt;&lt; POS) &amp; mask);
 return *this;
 }
};
</code></pre>

The above toy implementation allows for example to define a 12-bit field in a <code>unsigned long long</code> variable with

<pre><code>unsigned long long var;

BitField&lt;unsigned long long, 7, 12&gt; muxno(&amp;var);
</code></pre>

and the generated code to access the field value is just

<pre class="lang-none prettyprint-override"><code>0000000000000020 &lt;_Z6getMuxv&gt;:
 20: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax ; Get &amp;var
 27: 48 8b 00 mov (%rax),%rax ; Get content
 2a: 48 c1 e8 07 shr $0x7,%rax ; &gt;&gt; 7
 2e: 25 ff 0f 00 00 and $0xfff,%eax ; keep 12 bits
 33: c3 retq 
</code></pre>

Basically what you'd have to write by hand

blocks|key|2692693|text|我已经在C%2B%2B中编写了一个位字段的实现作为库的头文件。我在文档中给出的一个例子是，不写这样的代码：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2692694|struct+A
++{
++++union
++++++{
++++++++struct
++++++++++{
++++++++++++unsigned+x+:+5;
++++++++++++unsigned+a0+:+2;
++++++++++++unsigned+a1+:+2;
++++++++++++unsigned+a2+:+2;
++++++++++}
++++++++u;
++++++++struct
++++++++++{
++++++++++++unsigned+x+:+5;
++++++++++++unsigned+all_a+:+6;
++++++++++}
++++++++v;
++++++};
++};

//+…

A+x;
x.v.all_a+=+0x3f;
x.u.a1+=+0;|code-block|syntax|javascript|2692695|你可以这样写：|2692696|typedef+Bitfield<Bitfield_traits_default<>+>+Bf;

struct+A+:+private+Bitfield_fmt
++{
++++F<5>+x;
++++F<2>+a[3];
++};

typedef+Bitfield_w_fmt<Bf,+A>+Bwf;

//+…

Bwf::Format::Define::T+x;
BITF(Bwf,+x,+a)+=+0x3f;
BITF(Bwf,+x,+a[1])+=+0;|2692697|还有一个替代接口，在该接口下，上述代码的最后两行将更改为：|2692698|#define+BITF_U_X_BWF+Bwf
#define+BITF_U_X_BASE+x
BITF(X,+a)+=+0x3f;
BITF(X,+a[1])+=+0;|2692699|使用这种位字段的实现，特征模板参数为程序员提供了很大的灵活性。默认情况下，内存只是处理器内存，也可以是一种抽象，程序员提供执行“内存”读写的功能。抽象内存是任意无符号整数类型的元素序列(由程序员选择)。字段可以按重要性从低到高或从最低到最低的顺序进行布局。内存中字段的布局可以与它们在格式结构中的布局相反。|2692700|该实现位于：https://github.com/wkaras/C-plus-plus-library-bit-fields|offset|length|2692701|(如您所见，不幸的是，我无法完全避免使用宏。)|2692702|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/wkaras/C-plus-plus-library-bit-fields^0|0|0|0|0|0|0|0|6|1K|0|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|15|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|16|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|17|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|18|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|19|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|1A|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1B|8|@]|9|@$S|1C|T|1D|1|1E]]|A|$]]|$1|U|3|V|5|6|7|1F|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]]|X|$Y|$5|Z|10|11|A|$12|13]]]]

I have written an implementation of bit fields in C++ as a library header file. An example I give in the documentation is that, instead of writing this:

<pre><code>struct A
 {
 union
 {
 struct
 {
 unsigned x : 5;
 unsigned a0 : 2;
 unsigned a1 : 2;
 unsigned a2 : 2;
 }
 u;
 struct
 {
 unsigned x : 5;
 unsigned all_a : 6;
 }
 v;
 };
 };

// …

A x;
x.v.all_a = 0x3f;
x.u.a1 = 0;
</code></pre>

you can write:

<pre><code>typedef Bitfield&lt;Bitfield_traits_default&lt;&gt; &gt; Bf;

struct A : private Bitfield_fmt
 {
 F&lt;5&gt; x;
 F&lt;2&gt; a[3];
 };

typedef Bitfield_w_fmt&lt;Bf, A&gt; Bwf;

// …

Bwf::Format::Define::T x;
BITF(Bwf, x, a) = 0x3f;
BITF(Bwf, x, a[1]) = 0;
</code></pre>

There's an alternative interface, under which the last two lines of the above would change to:

<pre><code>#define BITF_U_X_BWF Bwf
#define BITF_U_X_BASE x
BITF(X, a) = 0x3f;
BITF(X, a[1]) = 0;
</code></pre>

Using this implementation of bit fields, the traits template parameter gives the programmer a lot of flexibility. Memory is just processor memory by default, or it can be an abstraction, with the programmer providing functions to perform "memory" reads and writes. The abstracted memory is a sequence of elements of any unsigned integral type (chosen by the programmer). Fields can be laid out either from least-to-most or most-to-least significance. The layout of fields in memory can be the reverse of what they are in the format structure.

The implementation is located at: <a href="https://github.com/wkaras/C-plus-plus-library-bit-fields" rel="nofollow noreferrer">https://github.com/wkaras/C-plus-plus-library-bit-fields</a>

(As you can see, I unfortunately was not able to fully avoid use of macros.)

blocks|key|2692786|text|C是为低级比特操作而设计的。声明一个包含无符号字符的缓冲区并将其设置为您想要的任何位模式非常简单。特别是如果你的位串非常短，那么就适合其中一个整型。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2692787|一个潜在的问题是字节顺序。C根本看不到这一点，但正如整数有字节序一样，字节在序列化时也有字节序。另一个原因是非常少的机器不使用八位字节。C保证一个字节至少是一个二进制八位数，但是32和9是真实的实现。在这种情况下，你必须决定是简单地忽略超比特(在这种情况下，朴素的代码应该可以工作)，还是将它们作为比特流的一部分(在这种情况下，你必须小心地将CHAR_BIT合并到计算中)。测试代码也很困难，因为你不太可能发现在CHAR%2BBIT+32机器上很容易上手。|2692788|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

C is designed for low-level bit manipulation. It's easy enough to declare a buffer of unsigned chars, and set it to any bit pattern you want. Especially if your bit strings are very short so fit into one of the integral types.

One potential problem is byte endiannness. C can't "see" this at all, but just as integers have an endianness, so too do bytes, when serialised. Another is the very small number of machines that don't use octets for bytes. C guarantees a byte shall be at least an octet, but 32 and 9 are real-world implementations. In those circumstances, you have to take a decision whether to simply ignore the uper bits (in which case naive code should work), or treat them as part of the bitstream (in which case you've got to be careful to fold CHAR_BIT into your calculations). It's also hard to test the code as you unlikely to find it easy to get your hands on a CHAR+BIT 32 machine.

blocks|key|2904838|text|在生产代码中，我们必须将MIPS代码移植到x86-64|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2904839|https://codereview.stackexchange.com/questions/54342/template-for-endianness-free-code-data-always-packed-as-big-endian|offset|length|2904840|对我们来说效果很好。|2904841|它基本上是一个没有任何存储的模板，模板参数指定了相关位的位置。|2904842|如果需要多个字段，您可以将模板的多个专门化放在一个联合中，并使用一个字节数组来提供存储。|2904843|该模板具有用于赋值的重载和用于读取值的unsigned转换运算符。|style|CODE|2904844|此外，如果字段大于一个字节，它们将以big-endian字节顺序存储，这在实现跨平台协议时有时很有用。|2904845|下面是一个使用示例：|2904846|union+header
{
++++unsigned+char+arr[2];+++++++//+space+allocation,+2+bytes+(16+bits)

++++BitFieldMember<0,+4>+m1;+++++//+first+4+bits
++++BitFieldMember<4,+5>+m2;+++++//+The+following+5+bits
++++BitFieldMember<9,+6>+m3;+++++//+The+following+6+bits,+total+16+bits
};

int+main()
{
++++header+a;
++++memset(a.arr,+0,+sizeof(a.arr));
++++a.m1+=+rand();
++++a.m3+=+a.m1;
++++a.m2+=+~a.m1;
++++return+0;
}|code-block|syntax|javascript|2904847|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|3B|0|0|0|0|0|J|8|0|0|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|16|8|@]|9|@$D|17|E|18|1|19]]|A|$]]|$1|F|3|G|5|6|7|1A|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1B|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1C|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1D|8|@$D|1E|E|1F|N|O]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1G|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1H|8|@]|9|@]|A|$]]|$1|T|3|U|5|V|7|1I|8|@]|9|@]|A|$W|X]]|$1|Y|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]]|Z|$10|$5|11|12|13|A|$14|C]]]]

We have this in production code where we had to port MIPS code to x86-64

<a href="https://codereview.stackexchange.com/questions/54342/template-for-endianness-free-code-data-always-packed-as-big-endian">https://codereview.stackexchange.com/questions/54342/template-for-endianness-free-code-data-always-packed-as-big-endian</a>

Works well for us.

It's basically a template without any storage, the template arguments specify the position of the relevant bits.

If you need multiple fields, you put multiple specializations of the template together in a union, together with an array of bytes to provide storage.

The template has overloads for assignment of value and a conversion operator to <code>unsigned</code> for reading the value.

In addition, if the fields are larger than a byte, they are stored in big-endian byte order, which is sometimes useful when implementing cross-platform protocols.

here's a usage example:

<pre><code>union header
{
 unsigned char arr[2]; // space allocation, 2 bytes (16 bits)

 BitFieldMember&lt;0, 4&gt; m1; // first 4 bits
 BitFieldMember&lt;4, 5&gt; m2; // The following 5 bits
 BitFieldMember&lt;9, 6&gt; m3; // The following 6 bits, total 16 bits
};

int main()
{
 header a;
 memset(a.arr, 0, sizeof(a.arr));
 a.m1 = rand();
 a.m3 = a.m1;
 a.m2 = ~a.m1;
 return 0;
}
</code></pre>

There are many situations (especially in low-level programming), where the binary layout of the data is important. For example: hardware/driver manipulation, network protocols, etc.

In C++ I can read/write arbitrary binary structures using <code>char*</code> and bitwise operations (masks and shifts), but that's tedious and error-prone. Obviously, I try to limit the scope of these operations and encapsulate them in higher-level APIs, but it's still a pain.

<a href="http://en.cppreference.com/w/cpp/language/bit_field" rel="noreferrer">C++ bitfields</a> seem to offer a developer-friendly solution to this problem, but unfortunately their storage is <a href="https://stackoverflow.com/questions/17723604/bitfields-why-implementation-specific">implementation specific</a>.

NathanOliver mentionned <code>std::bitset</code> which basically allows you to access individual bits of an integer with a nice <code>operator[]</code> but lacks accessors for multi-bit fields.

Using meta-programming and/or macros, it's possible to abstract the bitwise operations in a library. Since I don't want to reinvent the wheel, I'm looking for a (preferably STL or boost) library that does that.

For the record, I'm looking into this for a <a href="https://technet.microsoft.com/en-us/library/Dd197470(v=WS.10).aspx" rel="noreferrer">DNS</a> resolver, but the problem and its solution should be generic.

Edit: short answer: it turns out bitfield's storage is reliable in practice (even if it's not mandated by the standard) since system/network libraries use them and yeild well behaved programs when compiled with mainstream compilers.

Is there a portable alternative to C++ bitfields

编译器

在很多情况下(尤其是在低级编程中)，数据的二进制布局很重要。例如:硬件/驱动程序操作、网络协议等。在C++中，我可以使用char*和按位操作(掩码和移位)读/写任意二进制结构，但这样做很繁琐且容易出错。显然，我试图限制这些操作的范围，并将它们封装在更高级别的API中，但这仍然是一件痛苦的事情。似乎为这个问题提供了一个开...

问是否有可移植的替代C++位字段的方法
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问是否有可移植的替代C++位字段的方法EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问是否有可移植的替代C++位字段的方法
EN