c - 什么时候应该在嵌入式系统中使用类型抽象

Question

我研究过许多不同的嵌入式系统。他们都对 UINT32 等类型使用了 typedef(或 #defines)。

这是一个很好的技术，因为它可以让程序员了解类型的大小，并让您更加意识到溢出等的可能性。

但在某些系统上，您知道编译器和处理器在项目生命周期内不会改变。

那么什么会影响您创建和实现项目特定类型的决定？

编辑我想我已经失去了我的问题的要点，也许真的是两个。

对于嵌入式编程，您可能需要特定大小的接口(interface)类型，并且还要处理 RAM 等受限资源。这是无法避免的，但您可以选择使用编译器提供的基本类型。

对于其他一切，类型的重要性较低。
您需要注意不要引起溢出，并且可能需要注意寄存器和堆栈的使用。这可能会将您引向 UINT16、UCHAR。但是，使用诸如 UCHAR 之类的类型可能会使编译器变得“无足轻重”。由于寄存器通常较大，一些编译器可能会添加代码以将结果强制转换为类型。

i++;

可以变成

ADD REG,1AND REG, 0xFF

这是不必要的。

所以我认为我的问题应该是:-

考虑到嵌入式软件的限制，为一个将有很多人从事该项目的项目设置的最佳策略是什么——并非所有人都具有相同水平的经验。

Answer 1

我很少使用类型抽象。以下是我的论点，按照主观性递增的顺序排列:

1. 局部变量不同于结构成员和数组，因为您希望它们适合寄存器。在 32b/64b 目标上，本地 int16_t与本地 int 相比，可以使代码变慢，因为编译器必须根据 int16_t 的语义向/force/overflow 添加操作.虽然 C99 定义了一个 intfast_t typedef，据我所知，一个普通的 int 也适合寄存器，而且它肯定是一个更短的名称。

2. 喜欢这些 typedef 的组织几乎总是以其中的几个结尾( INT32, int32_t, INT32_T ，无穷无尽)。因此，在某种程度上，使用内置类型的组织最好只拥有一组名称。我希望人们使用 stdint.h 或 windows.h 或任何现有的 typedef；当目标没有那个 .h 文件时，添加一个有多难？

3. 理论上，typedef 可以帮助移植，但就我而言，我从未从中获得任何好处。是否有可以从 32b 目标移植到 16b 目标的有用系统？是否有一个 16b 系统可以轻松移植到 32b 目标？此外，如果大多数变量是整数，您实际上会从新目标的 32 位中获得一些东西，但如果它们是 int16_t ，你不会。而那些难以移植的地方，无论如何都需要人工检查；在尝试端口之前，您不知道它们在哪里。现在，如果有人认为如果到处都有 typedef 就可以很容易地移植东西 - 当需要移植时，很少有系统会发生这种情况，请编写一个脚本来转换代码库中的所有名称。这应该按照“无需人工检查”的逻辑进行工作，并将工作推迟到实际带来 yield 的时间点。

4. 现在，如果可移植性可能是 typedef 的理论上的好处，那么可读性肯定会付之东流。看看 stdint.h:{int,uint}{max,fast,least}{8,16,32,64}_t .种类很多。一个程序有很多变量；需要int_fast16_t真的那么容易理解吗？并且需要 uint_least32_t ？有多少次我们在它们之间默默地转换，使它们变得毫无意义？ (我特别喜欢 BOOL/Bool/eBool/boolean/bool/int 转换。由强制使用 typedef 的有序组织编写的每个程序都充斥着这种转换)。

5. 当然，在 C++ 中，我们可以通过使用重载运算符和其他东西将数字包装在模板类实例化中来使类型系统更加严格。这意味着您现在将收到格式为“class Number has no operator+ overload for argument of type class Number , candidates are...”的错误消息我也不要称之为“可读性”。正确实现这些包装类的机会微乎其微，而且大多数时候您将等待无数模板实例的编译。