The problem is that it's difficult to define what is allowed and what is
not.  "Fragile base class" problems are quite diverse.  In the end it's up
to you to use your own engineering judgment, but the recommendation from us
is that you look for designs that don't require subclassing protobuf
objects.
With respect to offset tables, I think the only way you could break those is
if you used multiple inheritance.  But it could depend on your compiler.  A
simple subclass that just adds new members *probably* won't break anything,
but C++ is so horribly complicated that it's hard to say for certain.

If you just want to add some custom members, why not define a struct/class
containing an instance of your message and those custom fields along side?

On Wed, Feb 4, 2009 at 3:22 PM, <fedor.labou...@gmail.com> wrote:

>
> > Sorry, but we don't allow subclassing of protocol buffer objects (in any
> > language).  Allowing this leads to too many "fragile base class"
> problems.
>
> Sorry to bring up an old topic again, and I know it's discouraged, but
> I was wondering if there would be any incompatibilities if the
> subclass would remain very simple, simply adding a couple of custom
> member variables and otherwise only calling public functions in its
> own functions.  Are there any binary structure dependencies that I'm
> not thinking of that would be broken(like the offsets table), or would
> this be a conservative enough subclassing?
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to