C++ interface

[GoogleCodeExporter]

It might be nice to provide an optional C++ interface for the generated 
structures. These would be mostly simple wrapper methods, like

void set_foo(int value) { foo = value; has_foo = true; }

This would provide easier porting to/from Google-official C++ interface.

It should probably be enabled with an option to the generator, in order not to 
pollute the C headers with unnecessary #ifdefs.

Original issue reported on code.google.com by Petteri.Aimonen on 13 Dec 2012 at 7:42

[GoogleCodeExporter]

Some more proposals for C++ interface:
* use classes instead of structs
* declare members protected
* En-/decode has_foo-information as bits with bit-shifts.

A lightweight C++ interface for protocol-buffers would be very cool.

Original comment by embedded...@gmail.com on 15 Feb 2013 at 12:06

[GoogleCodeExporter]

Thanks for your comments.

I agree that all of these would make perfect sense if nanopb was a C++-only 
library.

However, because I don't feel like maintaining two libraries, the interface has 
to be a compromise. Mainly it has to be compatible with the C interface, with 
just a bunch of C++ wrappers for easier use.

Classes vs. structs doesn't really matter anything in C++, it just sets default 
visibility. Could be #ifdeffed, but I don't see the point.

Protected members is possible. I guess it could be an option, as some people 
may want to use the C interface also from C++ code (i.e. if they are familiar 
to just type message.field = foo;), while other people want to enforce use of 
only the C++ interface (message.set_field(foo);).

Bitfield has_fields is a proposal that comes up every now and then. It has 
actually been implemented in dynamic_alloc branch. However the C interface is 
quite nasty. It may eventually happen, but it is a separate task from this C++ 
interface.

Original comment by Petteri.Aimonen on 15 Feb 2013 at 12:38

[GoogleCodeExporter]

"[..]if nanopb was a C++-only library."
This would be a really wonderful thing, simplifying many things (and 
complicating others ;). But I see your point, that the maintenance of two libs 
would (unfortunately) be pretty too much work.

Original comment by embedded...@gmail.com on 15 Feb 2013 at 1:34