使用uint8,uint16等

Neo*_*low 19 c c++ embedded memory-management

目前我正在使用针对32位MIPS平台的代码库(C,C++混合).处理器是一个相当现代的处理器[只是提到我们有很好的处理能力和内存].

代码库使用数据类型,如uint8 [1字节宽无符号整数],uint16 [2字节宽无符号整数],uint32 [4字节宽无符号整数]等.

我知道在将代码移植到不同平台时这些构造的用法是如何有用的.

我的问题是:

  1. 使用uint16有什么用/有用uint32也足够了(如果有的话)?

  2. 在使用较短的数据类型(考虑数据对齐)时,是否可以节省内存使用量?

  3. 如果要节省几个字节的内存,在现代硬件中做些什么是明智的吗?

Ale*_*nze 23

使用uint16有什么用/有用uint32也足够了(如果有的话)?

如果它们uint16s是数组或结构的一部分,则可以节省内存,并且可能能够处理比uint32s在相同数组或结构中更大的数据集.这真的取决于你的代码.

数据协议和文件格式可能会使用uint16s,而使用它可能不正确uint32s.这取决于格式和语义(例如,如果您需要将值从65535回绕到0,uint16则会自动执行,而uint32不会).

OTOH,如果那些uint16s只是单个局部或全局变量,用32位替换它们可能没有显着差异,因为它们可能由于对齐而占据相同的空间并且它们作为32位参数传递(在堆栈上或在MIPS中的寄存器)无论如何.

在使用较短的数据类型(考虑数据对齐)时,是否可以节省内存使用量?

可能会有节省,特别是当uint16s许多结构的一部分或大数组的元素时.

如果要节省几个字节的内存,在现代硬件中做些什么是明智的吗?

是的,您降低了内存带宽(这总是一件好事),并且当您操作较少的数据时,通常会降低各种缓存未命中(数据缓存和TLB).


Cli*_*ord 9

首先,如果您定义了uint16等类型,它们在哪里定义?它们不是标准类型,因此将在某些专有标题中定义 - 可能是您的或可能由某些第三方库提供; 在这种情况下,您必须问自己该代码的可移植性,以及您是否正在创建在某些其他应用程序中可能没有意义的依赖项.

另一个问题是许多库(不明智的IMO)使用各种名称定义这样的类型,例如UINT16,uint16,U16 UI16等,它变得有点像确保类型协议和避免名称冲突的噩梦.如果这样的名字定义,他们应该理想地被放置在一个命名空间或给定库特定的前缀以表示它们与使用被定义什么库,例如rtos::uint16rtos_uint16.

由于ISO C99标准库在stdint.h中提供了标准的位长特定类型,因此您应该优先使用它们在专有或第三方标头中定义的任何类型.这些类型具有_t后缀,例如uint16_t.在C++中,它们可能被放置在std::命名空间中(尽管这不是给定的,因为在C99中引入了标头).

1]使用uint16有什么用/有益的,uint32也足够了(如果有的话)?

除了我前面的建议,更喜欢stdint.huint16_t,也有使用长度特定类型的至少两个正当理由:

  1. 匹配特定的硬件寄存器宽度.
  2. 在不同体系结构中实施通用且兼容的API.

2]在使用较短的数据类型(考虑数据对齐)时,是否可以节省内存使用量?

可能,但如果记忆不是你的问题,那就不是使用它们的好理由.值得考虑的可能是大型数据对象或数组,但全球应用很少值得努力.

3]如果要节省几个字节的内存,在现代硬件中做些什么是明智的吗?

见[2].然而," 现代硬件 "并不一定意味着大量资源; 例如,有大量的32位ARM Cortex-M器件,只有几Kb的RAM.这更多是关于模具空间,成本和功耗,而不是设计或建筑时代.