简体繁体 English

protobuf-net是否缺少可选字段的has_函数？

[英]protobuf-net missing has_ function for optional fields?.

原文 2013-09-19 08:02:55 2 1 c#/ c++/ protobuf-net

We use protocol buffers for communication between native C++ apps, but also between native C++ app and .NET application (all is VS2012) via protobuf-net r666. 我们使用协议缓冲区在本机C ++应用程序之间进行通信，也使用本机C ++应用程序与.NET应用程序（全部为VS2012）之间通过protobuf-net r666进行通信。 We rely in C++ heavily on the has_ functions that are available for an optional element. 在C ++中，我们严重依赖于可用于可选元素的has_函数。

Eg if we have a message with a field optional bool, it can be that it is not set, it is set to true, or it is set to false. 例如，如果我们有一条带有可选布尔值的消息，则可能是未设置，将其设置为true或将其设置为false。

In C++ this can be checked with the function has_field and if set then the content can be fetched with get_field function. 在C ++中，可以使用has_field函数进行检查，如果已设置，则可以使用get_field函数获取内容。 If not set, and get_field is called, then the get returns the default, which if not explicitly set is false (for a boolean). 如果未设置，则调用get_field，则get返回默认值，如果未显式设置，则默认值为false（用于布尔值）。

This works perfectly in C++, but, in protobuf-net however, we cannot seem to find the equivalent of the has_ function, and, when the message is received, the field is added to the message and it's content is set to the default, being false. 这在C ++中可以完美运行，但是在protobuf-net中，我们似乎无法找到has_函数的等效项，并且在收到消息后，将字段添加到消息中，并将其内容设置为默认值，是假的。 It's not a disaster that the field is there with the default, but the problem is that there is no has_ function to check whether it was set in the message. 缺省情况下该字段存在不是什么麻烦，但问题是没有has_函数检查消息中是否设置了该字段。

Please advise whether this is a bug or whether we missed something in protobuf-net and that this actually is possible 请告知这是一个错误还是我们错过了protobuf-net中的某些东西，并且实际上这是可能的

Thx in advance. 提前谢谢。 Wim 维姆

1 个解决方案

(I know we already covered this in the issue tracker - this is purely for visibility etc) （我知道我们已经在问题跟踪器中介绍了此内容-纯粹是为了提高可见性等）

This relates to generating classes from .proto files, which in the case of protobuf-net is via the protogen tool. 这涉及从.proto文件生成类，对于protobuf-net而言，这是通过protogen工具生成的。 By default, it does not create the equivalent of has_* methods, but this can be enabled with the -p:detectMissing switch - which causes it to create *Specified accessors. 默认情况下，它不会创建等效的has_*方法，但是可以使用-p:detectMissing开关启用它-这将导致它创建*Specified访问器。 The naming here is a .NET idiom, with *Specified recognised by some other .NET serializers and internal code. 这里的命名是.NET惯用语，带有*Specified可以被其他.NET序列化程序和内部代码识别。 It also generates a private ShouldSerialize* method, which again helps some internal .NET code. 它还会生成一个私有的ShouldSerialize*方法，该方法再次可以帮助一些内部.NET代码。

In this specific case, there was a secondary issue with a member called value causing confusion; 在这种特定情况下，存在一个名为value的成员引起的第二个问题，引起混乱； the csharp.xslt file has now been updated to account for this. csharp.xslt文件现在已更新，可以解决此问题。

Update: in the fully managed rewrite, the ShouldSerialize*() method is generated by default when using proto2 syntax (the default). 更新：在完全托管的重写中，当使用proto2语法（默认设置）时，默认情况下会生成ShouldSerialize*()方法。 No additional parameter is required. 不需要其他参数。 The *Specified member is not added (it serves no additional purpose over ShouldSerialize*() . 未添加*Specified成员（除ShouldSerialize*()之外，它没有其他目的。

Note that when using proto3 , the changes to serialization rules mean that this concept no longer has meaning. 请注意，使用proto3 ，对序列化规则的更改意味着该概念不再有意义。 A value is serialized if and only if it is not the default, which is always null/false/zero/empty. 当且仅当该值不是默认值（始终为null / false /零/空）时，才会序列化该值。 There is no concept of "the default value but specified". 没有“默认值但已指定”的概念。 Because of this, the ShouldSerialize*() methods are generally no longer useful, and are not generated. 因此， ShouldSerialize*()方法通常不再有用，并且不会生成。 I'm open to making them optionally generated for proto3 , with them basically meaning "non-default", if that helps some genuine coding scenario. 我愿意选择为proto3生成它们，如果可以帮助某些真正的编码方案，它们的基本含义是“非默认值”。