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. 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.
Bottom line is, there's no definitive answer, and you'll need to weigh the trade-offs in the context of your application. On Thu, Nov 6, 2008 at 2:44 PM, codeazure <[EMAIL PROTECTED]> wrote: > > On Nov 7, 7:14 am, Kenton Varda <[EMAIL PROTECTED]> wrote: > > I've read your message a few times now and I have to admit I don't really > > understand what you're getting at. Can you give a small example of each > of > > the approaches you're considering? > > Sorry, I was a bit obtuse. I am considering two different approaches > to application design using PB. > > One design approach is to use the Facade design pattern and only use > PB data structures in the interface. Within a module, I use hand > written C++ data structures only & only pass these between modules > within the application. Then, there is a separate section of the > application that defines .proto files and their generated C++ files. > Interface functions translate the internal classes into the matching > PB messages and RPC declarations for external applications to use. > > A specific example of what this means is that if I have a variable > that may or may not be used, I might implement this using > boost::optional in my internal code. In the PB interface, I would > translate this into an extension that may or may not be defined in a > message. > > An alternative approach is to use PB message structures throughout the > module. All the code would use the PB generated functions for handling > extensions, accessor functions and so on. > > I understand that the primary aim of PB is for serialization of > messages. However, having all the support functionality for > extensions, and the accessor functions is handy in general > programming. If I use PB generated C++ data structures everywhere, > then it makes my application more flexible, making it easier to break > into pieces across multiple computers for example. > > The reason I'm hesitant about using PB data structures everywhere is > that I don't know what the memory and processing overhead is of using > them. > > I hope this makes my question clearer. > > Thanks, > Jeff > > > On Wed, Nov 5, 2008 at 12:06 AM, codeazure <[EMAIL PROTECTED]> wrote: > > > > > Does anyone have any thoughts on the use of PB message definitions for > > > interface only or throughout the implementation code as well? > > > > > I am planning a very modular application, where each module uses PB as > > > it's interface to external applications and inter-machine > > > communications within itself. > > > > > Should I be only writing PB definitions, generating C++ files and only > > > using those? Or should I write C++ headers with the implementation > > > version and only use PB for the interface? > > > > > I can easily imagine using a PB generated header file in my > > > implementation, calling the accessor functions & taking advantage of > > > the other support features in the Message class. But I'm not sure if > > > this is a good approach. > > > > > I understand that function calls are a different question & I should > > > only use RPC definitions when I am actually connecting to a remote > > > application, and not for internal function calls. > > > > > To put it another way, should I use the Bridge (or possibly Facade) > > > design pattern when using PB or should my data structures be defined > > > in one place only? > > > > > Thanks, > > > Jeff > > > --~--~---------~--~----~------------~-------~--~----~ 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 http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
