CODEWITHSUNDEEP
c#c++protocol-buffersprotobuf-net
Carlos
Carlos

Reputation: 6021

Protocol buffers, getting C# to talk to C++ : type issues and schema issues

I am about to embark on a project to connect two programs, one in c#, and one in c++. I already have a working c# program, which is able to talk to other versions of itself. Before I start with the c++ version, I've thought of some issues:

1) I'm using protobuf-net v1. I take it the .proto files from the serializer are exactly what are required as templates for the c++ version? A google search mentioned something about pascal casing, but I have no idea if that's important.

2) What do I do if one of the .NET types does not have a direct counterpart in c++? What if I have a decimal or a Dictionary? Do I have to modify the .proto files somehow and squish the data into a different shape? (I shall examine the files and see if I can figure it out)

3) Are there any other gotchas that people can think of? Binary formats and things like that?

EDIT I've had a look at one of the proto files now. It seems .NET specific stuff is tagged eg bcl.DateTime or bcl.Decimal. Subtypes are included in the proto definitions. I'm not sure what to do about bcl types, though. If my c++ prog sees a decimal, what will it do?

Upvotes: 5

Views: 780

Answers (2)

Marc Gravell
Marc Gravell

Reputation: 1064194

Some minor additions to Jon's points:

  • protobuf-net v1 does have a Getaproto which may help with a starting point, however, for interop purposes I would recommend starting from a .proto; protobuf-net can work this was around too, either via "protogen", or via the VS addin
  • other than that, you shouldn't have my issues as long as you remember to treat all files as binary; opening files in text mode will cause grief

Upvotes: 3

Jon Skeet
Jon Skeet

Reputation: 1503839

  1. Yes, the proto files should be compatible. The casing is about conventions, which shouldn't affect actual functionality - just the generated code etc.

  2. It's not whether or not there's a directly comparable type in .NET which is important - it's whether protocol buffers support the type which is important. Protocol buffers are mostly pretty primitive - if you want to build up anything bigger, you'll need to create your own messages.

  3. The point of protocol buffers is to make it all binary compatible on the wire, so there really shouldn't be gotchas... read the documentation to find out about versioning policies etc. The only thing I can think of is that in the Java version at least, it's a good idea to make enum fields optional, and give the enum type itself a zero value of "unknown" which will be used if you try to deserialize a new value which isn't supported in deserializing code yet.

Upvotes: 4

Related Questions