首先，这是我对这个问题的理解和思考。
-
为计数器或
for循环索引等单变量使用快速数据类型。例如:#define LOOP_COUNT (100U) uint_fast8_t index; for(index = 0; index < LOOP_COUNT; index++){ /* Do something */ }我想这里最合适的类型是
uint_fast8_t，因为index永远不会超过255，这将是所有平台上最快的实现。如果我使用unsigned int代替，它将在>=16位平台上最快，但在<16位平台上会慢一些，因为int是标准的最小16位。此外，如果我使用uint8_t，它将在>8位平台上变慢，因为编译器添加了AND 0xFF指令来检查每个增量的溢出(我的ARM7编译器即使在全速优化时也会这样做)。size_t也不是一个选项，因为它可以大于本机整数大小。坏的一面(?)如果溢出是预期的8位，它不会发生。程序员应该手动检查溢出(正如他/她应该做的那样)，如果忘记了，可能会导致代码错误。此外，如果LOOP_COUNT在>8位平台上"意外"设置为大于255的值，编译器(甚至令我惊讶的是PC-Lint)不会给出任何警告/问题，但警告将在8位平台上生成，这将降低可移植性并引入bug，但这可以通过
#if检查来避免。 -
如果在数组或结构体中需要考虑内存使用，则尽可能使用最少的数据类型。例如:
uint_least8_t array[100];如果考虑到内存使用，这是声明数组的最可移植和最有效的方式。如果平台上可以进行字节访问，则此类型将给出一个字节数组，否则将给出可访问宽度最小的整数数组。同样，如果有结构体的数组，也可以在结构体中使用least类型。
最小类型也可能遇到快速类型所遇到的问题，因为变量的宽度可以在不同的平台上更改。
-
尽可能避免固定宽度数据类型，因为它们可能在某些平台上甚至不存在，除了硬件寄存器访问，通信协议映射等，我们需要知道变量的确切位。例如:
typedef struct { uint8_t flags; uint8_t length; uint8_t data[100]; uint16_t crc; } __attribute__((packed)) package_t;通常应该使用
__attribute__((packed))(或类似的东西)来确保这些情况下不会插入填充，因为这本身可能是一个问题。
现在，如果我的理解是正确的，我认为最少的数据类型更有可能用于数组或结构，快速的数据类型更有可能用于单变量，固定的数据类型不太可能用于实现最大的可移植性和效率。但是每次输入"快速"one_answers"最少"并不是令人鼓舞的。所以，我认为类型集是这样的:
typedef [u]intN_t os_[u|s]exactN_t;
typedef [u]int_fastN_t os_[u|s]N_t;
/* I couldn't come up with a better name */
typedef [u]int_leastN_t os_[u|s]minN_t;
/* These may change */
typedef uint_least8_t os_byte_t;
typedef uint_least16_t os_word_t;
/* ... */
- 第一个重要的问题是，我的理解是正确的吗?
- 使用C99标准类型的最可移植和最有效的方法是什么?如果它不是真的，你将如何声明它们?
- 我的类型集是有意义的还是可能产生错误的代码?
另外，我很想知道你如何以及在哪里使用C99标准类型。
编写高度可移植的代码是困难的。编写高度可移植的、最佳的、正常工作的代码就更难了。
在大多数情况下，如果可行，我建议使用基本类型，如int, char等，而不是uint8_t或uint8_fast_t。保证类型int和char存在。这是毫无疑问的。当然，有时我们需要代码的特定行为，这就需要特定的类型——但是如果系统不支持这种类型，代码很可能会中断。
对于您的第一个示例，您极不可能获得比使用int更好的性能，除非您的代码被设计为(也)在8位处理器上运行。在16位、32位或64位处理器上，本机大小将是最快的for循环(unsigned在64位机器上稍微好一点，因为它不需要符号扩展)。
在第二个示例中，只有当数组足够大以保证比使用char或int或short或任何对内容有意义的东西节省空间时，它才真正重要。在现代机器上(包括许多嵌入式平台，甚至在使用堆栈时)400字节并不算多。
对于您的第三个示例，显然，对于协议，您需要使用与协议定义完全匹配的类型，否则会出错。在不支持正确类型的平台上，这个问题将不得不以某种特定于平台的方式来解决——如何解决这个问题将取决于平台实际支持什么。
那么，为了回答你的具体问题:
- 似乎你理解了整个概念。但你似乎也是试着把它推得更远，如果需要的话是有意义的。
- 不适用。
-
过度使用"特殊类型"变量可能会:
- 慢下来，
- 可能会导致错误，特别是如果不一致使用。
还要记住，性能通常是10%的代码占用了90%的时间。了解代码在什么地方(在正常使用情况下)花费时间是至关重要的。当然，在将代码移植到不同的系统和不同的体系结构时，您可能会发现性能瓶颈移动了，这取决于处理器速度、缓存大小和内存速度之间的关系。一个具有高处理器速度但(相对)小缓存的系统有时会比具有较低时钟速度和较大缓存的类似系统表现更差，这只是一个例子。