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, <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
