blocks|key|1879890|text|bool类型有一个曲折的历史，在语言运行时之间有许多不兼容的选择。这始于Dennis+Ritchie的一个历史性的设计选择，他发明了C语言。它没有bool类型，可选的是int，其中值0表示false，任何其他值都被认为是true。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1879891|这一选择在Winapi中得到了延续，这是使用pinvoke的主要原因，它有一个BOOL的类型定义函数，它是C编译器的int关键字的别名。如果您不应用显式的MarshalAs属性，那么C#布尔值将被转换为BOOL值，从而生成一个4字节长的字段。|offset|length|style|CODE|1879892|无论您做什么，您的struct声明都需要与您所使用的语言中的运行时选择相匹配。如上所述，BOOL用于winapi，但大多数C%2B%2B实现选择字节，大多数COM自动化互操作使用VARIANT_BOOL，它是一个缩写。|1879893|C#+bool的实际大小是一个字节。CLR的一个强大的设计目标是你找不到答案。布局是一个在很大程度上依赖处理器的实现细节。处理器对变量类型和对齐非常挑剔，错误的选择会严重影响性能并导致运行时错误。通过使布局不可发现，.NET可以提供不依赖于实际运行时实现的通用类型系统。|1879894|换句话说，你总是需要在运行时编组一个结构来确定布局。此时进行从内部布局到互操作布局的转换。如果布局相同，这可能会非常快；当字段需要重新排列时，速度会很慢，因为这总是需要创建结构的副本。这方面的技术术语是blittable，将blittable结构传递给本机代码是很快的，因为pinvoke编组程序可以简单地传递一个指针。|1879895|性能也是bool不是单比特的核心原因。很少有处理器可以让位直接寻址，最小的单位是一个字节。需要额外的指令来从字节中提取位，这不是免费的。而且它从来不是原子的。|1879896|使用sizeof(bool)，C#编译器不会害羞地告诉您它需要1个字节。这仍然不能很好地预测一个字段在运行时需要多少字节，CLR还需要实现.NET内存模型，并且它承诺简单的变量更新是原子的。这要求变量在内存中正确对齐，以便处理器可以在单个内存总线周期内对其进行更新。通常情况下，bool实际上需要4或8个字节的内存。为确保下一个成员正确对齐而添加的额外填充。|1879897|CLR实际上利用了布局不可发现的优势，它可以优化类的布局并重新排列字段，从而使填充最小化。比方说，如果你有一个包含bool+%2B+int+%2B+bool成员的类，那么它将占用1%2B+(3)+%2B4%2B1%2B+(3)字节的内存，(3)是填充，总共12字节。50%25的浪费。自动布局重新排列为1%2B1%2B+(2)+%2B4=8字节。只有类具有自动布局，默认情况下结构具有顺序布局。|1879898|更糟糕的是，在使用支持AVX指令集的现代C%2B%2B编译器编译的C%2B%2B程序中，bool可能需要多达32个字节。这施加了32字节的对齐要求，所以布尔变量可能以31字节的填充结束。这也是为什么.NET抖动不会发出单指令多数据指令的核心原因，除非显式包装，否则它不能获得对齐保证。|1879899|entityMap^0|0|13|4|0|0|3|4|0|0|0|2|C|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@$D|Z|E|10|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|11|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|12|8|@$D|13|E|14|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|15|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|16|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|17|8|@$D|18|E|19|F|G]]|9|@]|A|$]]|$1|R|3|S|5|6|7|1A|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1B|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|W|$]]

The bool type has a checkered history with many incompatible choices between language runtimes. This started with an historical design-choice made by Dennis Ritchie, the guy that invented the C language. It did not have a bool type, the alternative was int where a value of 0 represents false and any other value was considered true.

This choice was carried forward in the Winapi, the primary reason to use pinvoke, it has a typedef for <code>BOOL</code> which is an alias for the C compiler's int keyword. If you don't apply an explicit [MarshalAs] attribute then a C# bool is converted to a BOOL, thus producing a field that is 4 bytes long.

Whatever you do, your struct declaration needs to be a match with the runtime choice made in the language you interop with. As noted, BOOL for the winapi but most C++ implementations chose byte, most COM Automation interop uses VARIANT_BOOL which is a short.

The actual size of a C# <code>bool</code> is one byte. A strong design-goal of the CLR is that you cannot find out. Layout is an implementation detail that depends on the processor too much. Processors are very picky about variable types and alignment, wrong choices can significantly affect performance and cause runtime errors. By making the layout undiscoverable, .NET can provide a universal type system that does not depend on the actual runtime implementation.

In other words, you always have to marshal a structure at runtime to nail down the layout. At which time the conversion from the internal layout to the interop layout is made. That can be very fast if the layout is identical, slow when fields need to be re-arranged since that always requires creating a copy of the struct. The technical term for this is blittable, passing a blittable struct to native code is fast because the pinvoke marshaller can simply pass a pointer.

Performance is also the core reason why a bool is not a single bit. There are few processors that make a bit directly addressable, the smallest unit is a byte. An extra instruction is required to fish the bit out of the byte, that doesn't come for free. And it is never atomic.

The C# compiler isn't otherwise shy about telling you that it takes 1 byte, use <code>sizeof(bool)</code>. This is still not a fantastic predictor for how many bytes a field takes at runtime, the CLR also needs to implement the .NET memory model and it promises that simple variable updates are atomic. That requires variables to be properly aligned in memory so the processor can update it with a single memory-bus cycle. Pretty often, a bool actually requires 4 or 8 bytes in memory because of this. Extra padding that was added to ensure that the next member is aligned properly.

The CLR actually takes advantage of layout being undiscoverable, it can optimize the layout of a class and re-arrange the fields so the padding is minimized. So, say, if you have a class with a bool + int + bool member then it would take 1 + (3) + 4 + 1 + (3) bytes of memory, (3) is the padding, for a total of 12 bytes. 50% waste. Automatic layout rearranges to 1 + 1 + (2) + 4 = 8 bytes. Only a class has automatic layout, structs have sequential layout by default.

More bleakly, a bool can require as many as 32 bytes in a C++ program compiled with a modern C++ compiler that supports the AVX instruction set. Which imposes a 32-byte alignment requirement, the bool variable may end up with 31 bytes of padding. Also the core reason why a .NET jitter does not emit SIMD instructions, unless explicitly wrapped, it can't get the alignment guarantee.

I have two structs with arrays of bytes and booleans:

<pre><code>using System.Runtime.InteropServices;

[StructLayout(LayoutKind.Sequential, Pack = 4)]
struct struct1
{
 [MarshalAs(UnmanagedType.ByValArray, SizeConst = 3)]
 public byte[] values;
}

[StructLayout(LayoutKind.Sequential, Pack = 4)]
struct struct2
{
 [MarshalAs(UnmanagedType.ByValArray, SizeConst = 3)]
 public bool[] values;
}
</code></pre>

And the following code:

<pre><code>class main
{
 public static void Main()
 {
 Console.WriteLine("sizeof array of bytes: "+Marshal.SizeOf(typeof(struct1)));
 Console.WriteLine("sizeof array of bools: " + Marshal.SizeOf(typeof(struct2)));
 Console.ReadKey();
 }
}
</code></pre>

That gives me the following output:

<pre><code>sizeof array of bytes: 3
sizeof array of bools: 12
</code></pre>

It seems to be that a <code>boolean</code> takes 4 bytes of storage. Ideally a <code>boolean</code> would only take one bit (<code>false</code> or <code>true</code>, <code>0</code> or <code>1</code>, etc..).

What is happening here? Is the <code>boolean</code> type really so inefficient?

What is the size of a boolean In C#? Does it really take 4-bytes?

编译器

我有两个带有字节数组和布尔值的结构：using System.Runtime.InteropServices;[StructLayout(LayoutKind.Sequential, Pack = 4)]struct struct1{    [MarshalAs(UnmanagedType.ByValArray, Si...

问在C#中布尔值的大小是多少？它真的需要4个字节吗？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在C#中布尔值的大小是多少？它真的需要4个字节吗？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在C#中布尔值的大小是多少？它真的需要4个字节吗？
EN