问uint8_t T_BOOL；它还值得吗？

EN

它很简单：

如果您使用的是标准C，则使用stdbool.h中的

• 。_Bool也很好。丑陋的practice.
• If是不好的，你被迫与旧的C90一起工作，你必须使用某种丑陋的类型。

假设C90:

对布尔类型类型使用8位类型是绝对无害的。一个8位类型将节省一点内存。可以这样做：

typedef uint8_t BOOL;
#define FALSE 0u
#define TRUE  1u

然而，最常见的形式可能是typedef enum { FALSE, TRUE } BOOL;。

永远不要使用所有的小写！因为如果您将bool、false和true移植到标准C编译器，那么它们将与标准C编译器发生冲突。

所有这些自制的表格都是错误的做法，也是过时的书写方式。坚持使用危险的C90没有任何借口，特别是在安全关键的汽车系统中。

至于MISRA:2012，它只是简单地说明了应该有某种布尔类型。它保持与C90的向后兼容性，因此不强制使用bool。然而，它对于如何处理布尔类型有很多规则，并且避免了将它们与各种形式的算术一起使用。

为了与C++兼容，您绝对应该使用标准C bool。该类型的设计考虑到了C++的兼容性。

对于新代码，实际上没有理由重新定义标准类型--在我们的公司中，这意味着使用bool、true和false，因为它阻止不同的团队和开发人员开发自己的(有时是稍微不兼容的)这些类型的变体。

对于那些必须处理以前声明过的bool/true/false的旧代码(可能来自遗留框架)，将现有类型别名(通过ty胡枝子或#define)化成_Bool有时是有用的。这通常是框架而不是特定程序的问题。例子包括X11 (布尔)，Xt (_XtBoolean)，.

我认为，包含_Bool和bool的原因是允许已经创建了“bool”的现有代码继续工作，而不必由于引入“标准”bool、false和true而进行代码更改。

在使用C提升规则存储布尔值的瞬间，除了比较运算符(即int )传递的表达式的类型之外，您处于sin状态。还有一个更严肃的问题:我无法想象我存储布尔信息的类型会有什么影响，除了大量的布尔数据()之外，我已经编写了相当多的汽车软件任务关键部分，我很难想象这种数据结构可能有用的情况。几乎我处理过的每一个包含是/否决定的信息都包含了大量相关数据，因此，自然存储方案是一个结构。无论目前的米斯拉( MISRA )标准会怎么说，我都不会回避比特菲尔德(如果你戴着“理智的安全软件专家”(Sane Software )的帽子思考反诉，反对他们的理由就会化为灰烬)。如果不是这样，则是一些全局标志，因此存储格式的大小不受关注。所以问题是，还有哪些应用程序会影响布尔值的存储格式？我唯一能想到的就是堆栈大小，或者说，如果您没有选择最小的可用大小，就失去了只在寄存器中使用参数进行调用的可能性。这立即引发了两个反论点:具有许多松散耦合的布尔参数的函数非常可疑，即使它们存在，性能和内存消耗也不应该以任何方式依赖它们(如果它们是瓶颈，那也非常可疑)。如果有一个具有布尔值的调用层次结构，那么在最大堆栈大小方面可能会有一个小的胜利，但这不是进行微观优化的地方。

给出一个TL;DR的答案:格式不应该偏离您团队中(新的)程序员的期望，这很可能是过去十年中广泛使用/标准的格式。如果你的布尔人的存储类型真的那么重要，我，完全没有被问到，敢于远程诊断一个软件构建问题。