最佳实践:我应该在C或C ++中为字节创建typedef吗?

你更喜欢在代码中看到类似t_byte* (带有typedef unsigned char t_byte )或unsigned char*的东西吗?

我倾向于在我自己的图书馆中使用t_byte ,但从未参与过这种方法的大型项目,我对这些陷阱感到疑惑。

如果您使用的是C99或更新版本,则应使用stdint.huint8_t ,在这种情况下。

在C ++ 11之前,C ++没有得到这个头,称之为cstdint 。 旧版本的Visual C ++不允许您在C ++代码中使用C99的stdint.h ,但几乎所有其他C ++ 98编译器都这样做,因此即使使用旧编译器也可以使用该选项。

和其他很多东西一样, Boost在boost/integer.hpp这种差异,如果你的编译器的标准C ++库没有提供像uint8_t这样的东西。

我建议如果您的编译器支持它,请使用C99 头类型,例如uint8_tint8_t

如果您的编译器不支持它,请创建一个。 这是 VC ++ 的一个示例,其旧版本没有stdint.hGCC确实支持stdint.h ,实际上支持C99的大部分内容

您的建议的一个问题是char的符号是实现定义的,因此如果您确实创建了类型别名。 你应该至少明确一下这个标志。 这个想法有一些优点,因为在C#中 ,例如char是16bit。 但它也有一个字节类型。


附加说明……

你的建议没有问题,你确实指的是未签名的。

我还建议如果数据实际上是字符数据,则使用普通char ,即表示可能显示在控制台上的纯文本。 在使用标准库和第三方库时,这将显示更少的类型协议问题。 另一方面,如果数据表示非字符实体(如位图),或者如果它是数字’小整数’数据,您可以在其上执行算术运算,或者您将执行逻辑运算的数据,则其中一个应该使用stdint.h类型(或者甚至是从其中一个定义的类型)。

我最近遇到了一个TI C54xx编译器,其中char实际上是16位,所以这就是为什么在可能的情况下使用stdint.h ,即使你使用它然后定义一个byte类型,最好假设unsigned char是一个合适的别名。

我更喜欢使用类型来表达存储在其中的值的含义。 如果我需要一个描述字节的类型,就像在我的机器上一样,我非常喜欢byte_t unsigned char byte_t ,这可能意味着什么。 (我一直在使用signed charunsigned char来存储UTF-8字符串的代码库。) uint8_t 。 它可以只用作:8位无符号整数。

使用byte_t (与任何其他适当命名的类型一样),很少需要查找它定义的内容(如果是这样,一个好的编辑器将需要3secs来查找它;也许10secs,如果代码基础是巨大的),只要通过查看它就可以清楚地知道存储在该类型的对象中的内容。

我个人更喜欢boost::int8_tboost::uint8_t

如果您不想使用boost,可以借用boost\cstdint.hpp

另一种选择是使用stdint.h可移植版本 (来自这个答案的链接)。

除了你尴尬的命名惯例,我认为这可能没问题。 请记住,为您提供增强function,以帮助实现跨平台function:

 #include  typedef boost::uint8_t byte_t; 

请注意,通常类型的后缀为_t ,如byte_t

我更喜欢使用标准类型,unsigned char,uint8_t等,因此任何查看源代码的程序员都不必返回头部来查看代码。 您使用的typedef越多,其他人就越需要了解您的输入约定。 对于结构,绝对使用typedef,但对于基元,请谨慎使用它们。