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?
Bingo. For static arrays this obviously isn't necessary, but for
dynamically allocated arrays, the user can specify a field which will be
the count.
Wesley Tansey
Graduate Student
Department of Computer Science
Virginia Tech
http://people.cs.vt.edu/~tansey/
Bryan Ischo wrote:
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
_______________________________________________
gccxml mailing list
[email protected]
http://www.gccxml.org/mailman/listinfo/gccxml
