protocol-buffers - 在 Google Protocol Buffer 中是否有使用 int32 而不是 sint32 的好时机？

Question

我一直在阅读 Google Protocol Buffers最近，它允许在消息中使用各种标量值类型。

根据their documentation ，有三种类型的变长整数原语 - int32 , uint32 , 和 sint32 .在他们的文档中，他们注意到 int32是“对负数进行编码效率低下 - 如果您的字段可能有负值，请改用 sint32。”但是如果你有一个没有负数的字段，我认为 uint32 会比 int32 更好用。无论如何(由于处理负数的额外位和降低的 CPU 成本)。

那么int32什么时候是一个很好的标量吗？文档是否暗示只有当您很少得到负数时它才最有效？还是总是更喜欢使用sint32和 uint32 ，取决于字段的内容？

(同样的问题也适用于这些标量的 64 位版本: int64 、 uint64 和 sint64 ；但为了便于阅读，我将它们排除在问题描述之外。)

Answer 1

我不熟悉 Google Protocol Buffers，但我对文档的解释是:

如果值不能为负，则使用 uint32

使用 sint32 如果该值很可能是负数(对于“可能是”的一些模糊定义)

如果值可能为负数，则使用 int32，但这比正数的可能性要小得多(例如，如果应用程序有时使用 -1 表示错误或“未知”值，这是一种相对不常见的情况)

以下是文档对编码 ( http://code.google.com/apis/protocolbuffers/docs/encoding.html#types ) 的看法:

there is an important difference between the signed int types (sint32 and sint64) and the "standard" int types (int32 and int64) when it comes to encoding negative numbers. If you use int32 or int64 as the type for a negative number, the resulting varint is always ten bytes long – it is, effectively, treated like a very large unsigned integer. If you use one of the signed types, the resulting varint uses ZigZag encoding, which is much more efficient.

ZigZag encoding maps signed integers to unsigned integers so that numbers with a small absolute value (for instance, -1) have a small varint encoded value too. It does this in a way that "zig-zags" back and forth through the positive and negative integers, so that -1 is encoded as 1, 1 is encoded as 2, -2 is encoded as 3, and so on...

因此，即使您很少使用负数，只要您在协议(protocol)中传递的数字(包括非负数)的幅度较小，您最好使用 sint32 。如果您不确定，分析将是有序的。