时间戳

首页 > 解决方案 > typedef uint8_t T_BOOL; 还值得吗？

c - typedef uint8_t T_BOOL; 还值得吗？

问题描述

我正在审查 C 的编码指南，我们仍然有typedef uint8_t布尔值的指南。我在一家汽车行业的公司工作，因此从事嵌入式软件工作，并且通常使用 Renesas 微处理器和 GreenHills 编译器。

我认为由于 C99 已经存在这么多年，类型定义是多余的，我希望现代平台的所有编译器都支持_Bool. 那么，它还值得拥有typedef吗？

额外的问题：我正在尝试为 C++ 整理一些指南。我使用 C++ 的背景相对有限，但我再次认为typedefforbool根本不应该是有益的。我们应该使用基本的 C++bool类型还是有什么理由应该使用自定义的typedefT_BOOL 来代替？

标签： cembeddedgreenhillsautomotive

解决方案

很简单：

  • 如果您使用的是标准 C，则使用boolstdbool.h。_Bool也很好。丑陋的 typedef 是不好的，也是不好的做法。
  • 如果您被迫使用旧的 C90，则必须使用某种丑陋的 typedef。

假设 C90：

为布尔类型定义使用 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++ 兼容性。

推荐阅读