> This is a great discussion so far. I'm actually also working on a > similar tool to automate C++ serialization which uses GCCXML as its > first step. My approach is different in a few ways though: > > 1. It uses a visual tool. > 2. It's intended for the high performance computing (HPC) community. > 3. As a result of 2, the serialization is to MPI, not sockets. > > We've encountered most of the issues you guys have discussed in the > email, and I think with the visual tool we've solved all of them. The > tool allows the user to select a datatype from their program and then > gives them a treeview of the fields in that datatype. Then they just > check off what they want to serialize and click generate. The code then > gets generated to mirror MPI's normal Send, Recv, etc., calls so that it > looks like you're still using MPI calls but you're actually using the > code generated by the tool. > > If you guys are interested, we'll be submitting a paper on the complete > tool to ASE 2007 in early June. I can post a link to the paper and the > tool's website when it's all ready.
That is very cool. Please, do keep us informed of your progress. A question though: when you say that you allow the developer to visually select the fields of the datatype to serialize ... how do you handle arrays? When serializing an array, the number of elements to serialize must be known. Does your visual tool allow the selection of a field which the serializer should use as a "count" field? Or maybe you provide a way to enter a formula that the serializer can use to determine the count of elements in the array (expressed in terms of other fields of the data type)? One other application of serialization that I wanted to explore was object databases. I have read a little bit about Berkeley DB, which is the simple database system (it's really not much more than a system of persistent hashtables from what I can tell, with extra add-on support for things like indexes, transactions, etc) that for example MySQL is based on. Berkeley DB seems to me to be very robust and clean mostly due to its simplicity and focus: it deals *only* with saving blocks of data, it has no idea or care about the format of the blocks of data that you save. MySQL for example saves blocks of data which it formats in ways that represent relational database tables. I would be interested in using C++ serialization to create blocks of data which were C++ objects. Then you could use a C++ API based on C++ serialization and Berkeley DB which implemented a sort of database - more like a persistent C++ object storage mechanism, but I guess the addition of transaction and index support would make it more like a database. By the way - in terms of progress on Xrtti. I finished the test cases last night, they all work. I completed the "packaging" - for Linux anyway. I have RPM spec files so that Xrtti can be easily built as an RPM. What remains is: - Porting to other systems. I don't have build processes set up for building on alternate systems (I use a make-based build environment that I have not tested on anything except RedHat Linux so far). Also I rely on a portability layer of code which I have a Linux back end for but no other back ends (for example, no Microsoft Windows back end). - Testing with gccxml > 0.6 - Better documentation in the form of HOWTOs and FAQs However, if someone feels that what I have would be useful to them despite the above, please let me know and I will put the code up on my web site. It's all under the GPLv2, so you are free to use it in an open source project. You cannot release a commercial project which uses it though - but let me know if you want to, we can arrange an alternate license at very reasonable terms :) 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
