Generating .proto files from C++ classes

[MikeSP...@gmail.com]

Is there an existing convert that can take a header file and produce
a .proto file?

[Kenton Varda]

How would that work, exactly?

[MikeSP...@gmail.com]

SWIG is an example of a project that does something in the same vein.

On Jan 7, 1:50 pm, Kenton Varda <ken...@google.com> wrote:
> How would that work, exactly?
>

> On Wed, Jan 7, 2009 at 11:50 AM, MikeSParr...@gmail.com <

[Kenton Varda]

SWIG translates C/C++ APIs into other programming languages.  Protocol Buffers is not a programming language, so I don't see the analogy.  What would be the protocol buffer equivalent of a C function or a C++ class?

[Alek Storm]

On Jan 7, 4:21 pm, Kenton Varda <ken...@google.com> wrote:
> SWIG translates C/C++ APIs into other programming languages.  Protocol
> Buffers is not a programming language, so I don't see the analogy.  What
> would be the protocol buffer equivalent of a C function or a C++ class?

Technically, SWIG generates wrappers around C/C++ APIs from header
files so higher-level languages can call them. This is roughly what
he wants to do for Protocol Buffers: generate .proto schemas from C++
header files. He might want to look into extending the Boost
Serialization library somehow.

[Alek Storm]

Mike, what exactly are you trying to accomplish? Do you just want to
persist a C++ class? If so, you don't need to generate a .proto file,
because other languages won't need to read it, and you know your own
encoding layout. So you could still use the Protocol Buffers wire
format.

[Kenton Varda]

Protocol buffers are useful even if all users are using the same language.  In fact, we used them in C++ for some time before anyone bothered writing Java and Python implementations.

[Alek Storm]

Right, I guess I didn't explain why they don't work in this case.
Generating .proto files from C++ headers is obviously the reverse of
the normal sequence. In the PB method of versioning, the
original .proto is written and deployed. The next version then writes
an extension of the original. If the .proto file is generated from C+
+ headers, every time the headers are changed, the .proto is wiped out
and replaced with a new one. This is dangerous if a new C++ class
version redefines a field - it would break old code.

To sum up, you'd lose the benefits of the PB versioning system. You
certainly could generate .proto files from C++, but I don't know what
you'd use them for - if you wanted to generate, for example, Java
bindings from them, then just write the .proto file manually in the
first place and generate C++ and Java bindings from that.

That being said, you could still use the Protocol Buffers wire format,
but you'd probably need to add a version tag to each message. You can
use extend the Boost Serialization library for this, and Mike, I have
a note or two on this if you're interested.

And there's still the possibility that I've completely missed
something :)

[Kenton Varda]

On Wed, Jan 7, 2009 at 5:39 PM, Alek Storm <alek....@gmail.com> wrote:

Right, I guess I didn't explain why they don't work in this case.
Generating .proto files from C++ headers is obviously the reverse of
the normal sequence.  In the PB method of versioning, the
original .proto is written and deployed.  The next version then writes
an extension of the original.  If the .proto file is generated from C+
+ headers, every time the headers are changed, the .proto is wiped out
and replaced with a new one.  This is dangerous if a new C++ class
version redefines a field - it would break old code.

To sum up, you'd lose the benefits of the PB versioning system.  You
certainly could generate .proto files from C++, but I don't know what
you'd use them for - if you wanted to generate, for example, Java
bindings from them, then just write the .proto file manually in the
first place and generate C++ and Java bindings from that.

Yep, good points.

 

That being said, you could still use the Protocol Buffers wire format,
but you'd probably need to add a version tag to each message.  You can
use extend the Boost Serialization library for this, and Mike, I have
a note or two on this if you're interested.

IMO, there's not much reason to use the protobuf wire format unless you explicitly intend for some users to read/write the format using actual protocol buffers.

[Alek Storm]

On Jan 7, 8:18 pm, Kenton Varda <ken...@google.com> wrote:
> IMO, there's not much reason to use the protobuf wire format unless you
> explicitly intend for some users to read/write the format using actual
> protocol buffers.

Not entirely sure what you mean. This will probably get a lot clearer
once we get Mike's requirements.