[GCC-XML] Xrtti.h
Bryan Ischo
bji-gccxml at ischo.com
Thu Apr 26 17:20:57 EDT 2007
> 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 bryan at ischo.com 2001 Mazda 626 GLX
Hamilton, New Zealand http://www.ischo.com RedHat Fedora Core 5
------------------------------------------------------------------------
More information about the gccxml
mailing list