On Nov 7, 11:06 am, Kenton Varda <[EMAIL PROTECTED]> wrote:
> I think either approach can work, and the trade-offs depend on your
> application.  If your protocol messages are very complex, for instance, then
> maintaining parallel C++ classes can be a huge pain.  On the other hand,
> protocol message classes are essentially structs, whereas with hand-written
> C++ classes you can do better data encapsulation and such.
> As far as overhead goes, protocol message objects are approximately
> equivalent to structs in both size and access speed, so there's not much to
> worry about there.  Avoiding the conversion between protobufs and internal
> structures may save time.  

This is encouraging - it removes my worries about the overhead of
using them widely.

> On the other hand, if your data doesn't fit well
> into the protobuf model, it may be less efficient than it could be.  For
> example, if you are representing a graph, you cannot have each node contain
> pointers to all nodes it connects with, because protocol messages must be
> tree-shaped.

I think that internally I will still be using STL containers to hold
collections of messages in various forms. The container itself does
the job of defining the relationship between messages (list, set,
tree, etc), so there shouldn't be a conflict.

I will provide RPC functions that provide external applications a
functional interface to the internal structures. This makes it an easy
separation & means I don't have to double up the work with internal
data structures.

> Bottom line is, there's no definitive answer, and you'll need to weigh the
> trade-offs in the context of your application.

Thanks for the useful feedback,
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 [EMAIL PROTECTED]
For more options, visit this group at 

Reply via email to