我正在查看C的编码准则，但对于布尔值，我们仍然有typedef uint8_t的准则。我在汽车行业的一家公司工作，因此从事嵌入式软件的开发，通常与瑞萨微处理器和GreenHills编译器一起工作。
我认为，由于C99已经存在了很多年，所以类型定义是多余的，我希望现代平台的所有编译器都支持_Bool。因此，仍然值得拥有typedef吗？
奖金问题：：我正在尝试整理一些有关C ++的准则。我使用C ++的背景相对有限，但是我再次认为typedef的{{1}}完全没有好处。我们应该使用基本的C ++ bool类型还是出于某种原因而应使用自定义的bool ed T_BOOL？
很简单：
bool。 _Bool也可以。 不好的typedef不好，不好的做法。 假设C90：
为布尔型typedef使用8位类型绝对没有害处。 8位类型将节省一点RAM。可以这样完成：
typedef uint8_t BOOL;
#define FALSE 0u
#define TRUE 1u
最常见的形式可能是typedef enum { FALSE,TRUE } BOOL;。
切勿使用所有小写字母！由于bool，false和true如果移植到标准C编译器，将与标准冲突。
所有这些自制形式都是错误的做法，并且是过时的编写C的方式。没有任何借口坚持使用危险的C90，尤其是在对安全性要求严格的汽车系统中更是如此。
对于MISRA-C：2012，它只是声明您应该具有某种布尔类型。它保持与C90的向后兼容性，因此不强制执行bool。但是，对于如何处理布尔类型，它有很多规则，并且避免将它们与各种形式的算术一起使用。
为了与C ++兼容，您绝对应该使用标准C bool。该类型在设计时明确考虑了C ++兼容性。
对于新代码，实际上没有理由重新定义标准类型-在我们公司中，我们要求，暗示使用bool，true和false，因为这样做可以防止不同的团队和开发人员开发他们自己的（有时有些不兼容）这些类型的变体。
对于必须处理先前声明的bool / true / false（可能来自旧框架）的较旧代码，有时（通过typedef或#define）将现有类型别名为_Bool很有用。这通常是框架的问题，而不是特定的程序。示例包括X11（布尔），Xt（_XtBoolean），...
我相信同时包含_Bool和bool的原因是允许已经创建“ bool”的现有代码继续工作，而不必由于引入“标准” bool（假和真）而进行代码更改。
,在您（ab）使用C提升规则将布尔值存储在比较运算符所传递的表达式类型（即int）之外的任何其他情况下，您都处于犯罪状态。更严重的一点是：我不能设想这样的情况：我存储布尔信息的类型很重要，除了大量数量的布尔值，并且写了很多关键任务在汽车软件方面，我很难想象会有这样的数据结构有用的情况。我曾经处理过的是/否决定的几乎所有信息也都携带了一堆相关数据，因此自然存储方案就是一个结构。不管当前的MISRA标准怎么说，我从不回避位域（如果您戴着“ Sane安全软件专家”的帽子进行反驳，那么反对它们的案例就会尘土飞扬）。如果不是这种情况，则它是一些全局标志，因此不需要考虑存储格式的大小。所以问题是，布尔值的存储格式对剩下的哪些应用程序有影响？我唯一能想到的就是堆栈大小，如果您没有选择最小的可用大小，就失去了仅在寄存器中进行参数调用的可能性。这立即引起两个反驳：具有许多松散耦合的布尔参数的函数非常可疑，即使它们存在，性能和内存消耗也不应该以任何方式依赖它们（如果它们是瓶颈，那也就非常可疑）。如果您的调用层次结构在此处和那里都具有布尔值，则最大堆栈大小可能会很小，但这不是IME进行微优化的地方。
给出一个TL; DR答案：格式不应偏离您团队中（新）程序员的期望，并且很可能是最近十年来广泛使用/标准的格式。 如果您的布尔值的存储类型真的很重要，而我完全不敢问，那么就敢于远程诊断软件构造问题。