> I was waiting for someone to ask that question, as it took us about a > week of mind-racking to come up with a solution. Unfortunately, since > it's one of the key novel contributions for our work, I can't release > the details until after the June 4th ASE submission deadline. I hate > having to keep certain things a secret, but suffice it to say that when > we do release it, you'll definitely get an "ah-ha!" moment (after > spending about an hour trying to figure out what the heck is going on). :)
I'll be very interested in seeing your solution. I hope you don't mind if in the meantime I try to figure it out for myself :) > However, for a temporary solution, why not use the friend keyword? That > was our initial idea. Also, for #5 I know of at least one tool, C++2MPI > (not based on GCCXML), which does something very similar but slightly > tweaked due to the way that MPI works. As to the friend keyword - that would work too. But it would require that all classes which are to be serialized have a "friend Serializer;" or some such statement added to their definition. Wherever possible, I am trying to eliminate requirements of the developer in adding special code to their classes to enable serialization. Many such techniques require class definers to put "DECLARE_PROXY" or other strange macros at the front of their class definitions; that always leaves a bad taste in my mouth so I try to avoid anything special like that. My goal really and truly is to make serialization come "for free" for a developer - just run the serialization-generation tool at build time and instantly, all of your classes are serializable without any additional work or special friend declarations or macros in the class definitions. It truly saddens me that not every C++ class can be serialized due to the "how many elements are in the array" problem, because it means that developers do have to be aware of a couple of caveats when defining their classes that they intend to be serialized. But in every case where it is possible, I try to make serialization come without any extra steps from the developer. Hence I avoid "friend" and macro requirements. It's one of my philosophies of development that it should be priority #1 of each developer to make everyone else's job easy wherever possible. So when a new framework or tool is developed, the developer should first think, how can I write this so that it requires the minimum of explanation of how to use it? How can I design this so that its use follows naturally from the problem that it is attempting so solve, so that it will seem like the obvious way to do things to the developer who needs this tool? Of course you can't sacrifice functionality or correctness to this goal, and of course not everyone would do things the same way so you can't always make everything obvious to everyone, but I think it's a good goal to have nonetheless. What I think would be awesome is if the C++ language incorporated serialization into its definition. My serialization-generation stuff could work even better *in the compiler* instead of as a secondary code-generation step. Maybe someday ... Here are a couple of fundamental rules that I think would really help the software development community: 1. No programming language should be defined without a way to serialize data structures of the language. Languages typically specify in-memory (transient) representations of data structurs (ABIs) - why not also specify on-disk (persistent) representations also? 2. No RFC or "standard" (such as XML) should ever be written without a complete reference implementation. An RFC should be rejected until there is a reference implementation proving its feasability. If this rule were followed, it would keep standards from being defined that end up being a real pain in the butt to implement, because the designer of the standard would have to "eat their own dog food" and implement the thing, probably leading to simplifying and streamlining in many cases where the designer didn't realize the actual complexities of the design. Anyway, just a couple of things to think about ... Thanks, and best wishes, Bryan ------------------------------------------------------------------------ Bryan Ischo [EMAIL PROTECTED] 2001 Mazda 626 GLX Hamilton, New Zealand http://www.ischo.com RedHat Fedora Core 5 ------------------------------------------------------------------------ _______________________________________________ gccxml mailing list [email protected] http://www.gccxml.org/mailman/listinfo/gccxml
