有没有使用这些库经验的人对他们更喜欢哪一个有任何评论？使用中是否存在性能差异或困难？
【问题讨论】：
标签： c++ performance serialization protocol-buffers boost-serialization
我从来没有使用 boost 的库实现过任何东西，但我发现 Google protobuff 更经过深思熟虑，而且代码更简洁易读。我建议您查看您想要使用的各种语言，并阅读代码和文档并下定决心。
我使用 protobufs 遇到的一个困难是他们在生成的代码 GetMessage() 中命名了一个非常常用的函数，这当然与 Win32 GetMessage 宏冲突。
我仍然强烈推荐 protobufs。它们非常有用。
【讨论】：
GetMessage 障碍。需要考虑的事情......
我没有使用 boost 序列化的经验，但我使用过协议缓冲区。我非常喜欢协议缓冲区。请记住以下几点（我在 不知道提升的情况下这么说）。
希望这会有所帮助。
【讨论】：
boost.serialization 只需要 C++ 编译器并为您提供一些语法糖，例如
serialize_obj >> archive;
// ...
unserialize_obj << archive;
用于保存和加载。如果 C++ 是您使用的唯一语言，您应该认真对待 boost.serialization。
我快速浏览了 google 协议缓冲区。从我所看到的情况来看，我会说它与 boost.serialization 没有直接的可比性。您必须将 .proto 文件的编译器添加到您的工具链并维护 .proto 文件本身。 API 不像 boost.serialization 那样集成到 C++ 中。
boost.serialization 很好地完成了它设计的工作：序列化 C++ 对象 :) OTOH 像 google 协议缓冲区这样的查询 API 为您提供了更大的灵活性。
由于到目前为止我只使用了 boost.serialization，我无法对性能比较发表评论。
【讨论】：
我在这两个系统上都玩了一点，没什么大不了的，只是一些简单的骇人听闻的东西，但我觉得你应该如何使用这些库有很大的不同。
使用 boost::serialization，您首先编写自己的结构/类，然后添加归档方法，但您仍然留下了一些非常“苗条”的类，它们可以用作数据成员、继承等.
使用协议缓冲区，即使是一个简单的结构，生成的代码量也相当可观，并且生成的结构和代码更多地用于操作，并且您使用协议缓冲区的功能来传输数据到您的自己的内部结构。
【讨论】：
我已经使用 Boost Serialization 很长时间了，只是深入研究了协议缓冲区，我认为它们的用途并不完全相同。 BS（没看到）将您的 C++ 对象保存到流中，而 PB 是您读取/读取的交换格式。
PB 的数据模型要简单得多：您可以获得各种整数和浮点数、字符串、数组、基本结构，仅此而已。 BS 允许您一步直接保存所有对象。
这意味着使用 BS，您可以在线获取更多数据，但不必重建所有对象结构，而协议缓冲区更紧凑，但在读取存档后还有更多工作要做。顾名思义，一种用于协议（与语言无关，节省空间的数据传递），另一种用于序列化（节省对象）。
那么对您来说更重要的是：速度/空间效率还是简洁的代码？
【讨论】：
提升序列化
协议缓冲区
Boost 序列化是一个用于将对象转换为序列化数据流的库。协议缓冲区做同样的事情，但也为您做其他工作（如版本控制和字节序交换）。对于“小型简单任务”，Boost 序列化更简单。协议缓冲区可能更适合“更大的基础设施”。
编辑：24-11-10：将“自动”添加到 BS 版本控制中。
【讨论】：
关于Boost序列化的更正（猜猜这是that answer）：
它确实允许支持data versioning。
如果您需要压缩 - 使用压缩流。
可以处理平台之间的字节序交换，因为编码可以是文本、二进制或 XML。
【讨论】：
关于 boost.serialization 有几个额外的问题，我将添加到组合中。警告：除了浏览文档之外，我对协议缓冲区没有任何直接经验。
请注意，虽然我认为 boost 和 boost.serialization 的功能非常出色，但我得出的结论是，它附带的默认存档格式不是有线格式的好选择。
区分你的类的版本很重要（正如其他答案中提到的，boost.serialization 对数据版本控制有一些支持）和不同版本的序列化库之间的兼容性 em>。
boost.serialization may not generate archives that older versions can deserialize 的较新版本。（反之则不然：较新版本总是旨在反序列化旧版本制作的档案）。这给我们带来了以下问题：
Google 似乎实际上是 publish the protocol buffers wire format，而 Wikipedia 将它们描述为 forwards-compatible, backwards-compatible（尽管我认为 Wikipedia 指的是数据版本控制而不是协议缓冲区库版本控制）。虽然这些都不能保证前向兼容性，但对我来说这似乎是一个更强有力的指示。
总之，当我无法同步升级客户端和服务器时，我更喜欢众所周知的、已发布的有线格式，例如协议缓冲区。
脚注：我的 related answer 的无耻插件。
【讨论】：
与工程领域的几乎所有事情一样，我的回答是……“这取决于。”
两者都是经过充分测试和审查的技术。两者都会获取您的数据并将其转换为适合发送到某个地方的数据。两者都可能足够快，如果你真的在这里或那里计算一个字节，你可能不会对任何一个感到满意（让我们面对它创建的数据包将是 XML 或 JSON 的一小部分）。
对我来说，这实际上归结为工作流程，以及您是否需要 C++ 以外的其他东西。
如果您想首先弄清楚您的消息内容并且您正在从头开始构建一个系统，请使用协议缓冲区。您可以以抽象的方式考虑消息，然后以您想要的任何语言自动生成代码（几乎所有内容都可以使用 3rd 方插件）。此外，我发现使用 Protocol Buffers 简化了协作。我只需发送一个 .proto 文件，然后其他团队就可以清楚地了解正在传输的数据。我也不会对他们强加任何东西。如果他们想使用 Java，那就去吧！
如果我已经在 C++ 中构建了一个类（并且这种情况经常发生）并且我现在想通过网络发送该数据，那么 Boost 序列化显然很有意义（尤其是在我已经有了 Boost 的情况下）依赖于其他地方）。
【讨论】：
您可以将 boost 序列化与“真实”域对象紧密结合使用，并序列化完整的对象层次结构（继承）。 Protobuf 不支持继承，所以你必须使用聚合。人们认为 Protobuf 应该用于 DTO（数据传输对象），而不是核心域对象本身。我同时使用了 boost::serialization 和 protobuf。应该考虑 boost::serialization 的性能，cereal 可能是一个替代方案。
【讨论】：
我知道这是一个老问题了，但我想我会把我的 2 便士扔进去！
有了 boost，您就有机会在您的课程中编写一些数据验证；这很好，因为数据定义和有效性检查都在一个地方。
使用 GPB，您能做的最好的事情就是将 cmets 放入 .proto 文件中，并希望所有使用它的人都能阅读它、关注它并自行实施有效性检查。
不用说，如果您依靠网络流另一端的其他人以与自己相同的活力来执行此操作，这不太可能且不可靠。此外，如果对有效性的约束发生变化，则需要计划、协调和完成多个代码更改。
因此，我认为 GPB 不适合很少有机会与所有团队成员定期会面和交谈的开发。
==编辑==
我的意思是这样的：
message Foo
{
int32 bearing = 1;
}
现在谁来说bearing 的有效范围是多少？我们可以有
message Foo
{
int32 bearing = 1; // Valid between 0 and 359
}
但这取决于其他人阅读并为其编写代码。例如，如果你编辑它并且约束变为：
message Foo
{
int32 bearing = 1; // Valid between -180 and +180
}
您完全依赖于使用此 .proto 更新其代码的每个人。这是不可靠且昂贵的。
至少使用 Boost 序列化，您正在分发单个 C++ 类，并且可以在其中内置数据有效性检查。如果这些限制条件发生变化，那么除了确保他们使用与您相同版本的源代码外，其他人无需做任何工作。
替代方案
还有一个替代方案：ASN.1。这是古老的，但有一些非常非常方便的东西：
Foo ::= SEQUENCE
{
bearing INTEGER (0..359)
}
注意约束。因此，每当有人使用此 .asn 文件、生成代码时，他们最终都会得到自动检查 bearing 是否介于 0 和 359 之间的代码。如果您更新 .asn 文件，
Foo ::= SEQUENCE
{
bearing INTEGER (-180..180)
}
他们需要做的就是重新编译。无需更改其他代码。
你也可以这样做：
bearingMin INTEGER ::= 0
bearingMax INTEGER ::= 360
Foo ::= SEQUENCE
{
bearing INTEGER (bearingMin..<bearingMax)
}
注意<。而且在大多数工具中，bearingMin 和bearingMax 可以在生成的代码中显示为常量。这非常有用。
约束可能非常复杂：
Garr ::= INTEGER (0..10 | 25..32)
看看这个PDF中的第13章；你能做的真是太棒了；
数组也可以被约束：
Bar ::= SEQUENCE (SIZE(1..5)) OF Foo
Sna ::= SEQUENCE (SIZE(5)) OF Foo
Fee ::= SEQUENCE
{
boo SEQUENCE (SIZE(1..<6)) OF INTEGER (-180<..<180)
}
ASN.1 是老式的，但仍在积极开发、广泛使用（您的手机经常使用它），并且比大多数其他序列化技术更灵活。我能看到的唯一不足是没有像样的 Python 代码生成器。如果您使用的是 C/C++、C#、Java、ADA，那么免费（C/C++、ADA）和商业（C/C++、C#、JAVA）工具的组合将为您提供很好的服务。
我特别喜欢二进制和基于文本的线格式的广泛选择。这使得它在某些项目中非常方便。有线格式列表目前包括：
0 和15 之间的INTEGER 将只占用线路上的4 bits）加上其他人。
注意最后两个？是的，您可以在 ASN.1 中定义数据结构、生成代码并以 XML 和 JSON 格式发出/使用消息。对于一项始于 1980 年代的技术来说还不错。
版本控制与 GPB 不同。您可以允许扩展：
Foo ::= SEQUENCE
{
bearing INTEGER (-180..180),
...
}
这意味着以后我可以添加到Foo，具有此版本的旧系统仍然可以工作（但只能访问bearing 字段）。
我对 ASN.1 的评价很高。处理起来可能很痛苦（工具可能要花钱，生成的代码不一定漂亮，等等）。但是这些限制是一个真正奇妙的功能，它一次又一次地为我节省了大量的心痛。当编码器/解码器报告他们生成了 duff 数据时，开发人员会发牢骚。
其他链接：
观察
共享数据：
所以对我来说，ASN.1 做到了。它是最不可能导致其他人犯错的那个，因为它具有正确的功能，并且所有工具似乎都在努力完全实现这些功能，并且对于大多数用途而言，它是语言中立的。
说实话，如果 GPB 添加了约束机制，那将是赢家。 XSD 很接近，但这些工具几乎都是垃圾。如果有其他语言的不错的代码生成器，JSON 模式会非常好。
如果 GPB 添加了约束（注意：这不会改变任何有线格式），那将是我向所有人推荐的几乎所有用途的约束。虽然 ASN.1 的 uPER 对于无线电链路非常有用。
【讨论】：