RE: [libxml++] Putting values in a decent data structure



> On Tue, 2004-06-01 at 03:35, Daniel Holbach wrote:
> > I want to read a XML file and stick into a data structure 
> of my own; I

I've played around with using gccxml
and/or SWIG to automatically generate
the code that reads the XML and transfers
the data to the C/C++ struct/class,
and vice versa.

I've demoed it, but have not written a generic
tool yet.  Some of the junior guys in my group
have been using gccxml more and more, at my suggestion.

Here're some notes that may help you if you pursue
this direction:

   * gccxml is "more accurate", because it is based
     on the GCC compiler.  Unfortunately, it requires
     patches to be applied to the compiler, 
     and they are to an older version of GCC that 
     cannot compile some of the C++ code my group generates.

   * SWIG is "nicer" because it does not lose info
     such as #defines.
   * gccxml loses most info about enums.

   * SWIG doesn't understand nested class definitions

Currently, we are emphasizing gccxml because SWIG's
intrinsic limits wrt nested classes, etc., mean that
it cannot handle much of our code.  However, my guess
is that gccxml is going to die out over time; eventually
SWIG will be good enough.

Here's the basic flow:

   * gccxml generates an XML representation of the
     program, in particular the structs/classes.
     Call this datastructure-def.xml.

   * my/your tool takes datastructure-def.xml,
     and generates a C/C++ program that 
     knows how to read from an XML datastructure
     - call this second thing datastructure-value-instance.xml
     - and write to the C/C++ fields.
     Call the code generated by this 
     xml-serializer-Foo.cpp, for class Foo.

   * Now you compile xml-serializer-Foo.cpp,
     link it into your program, and you are off!

You can avoid the code generation step 
by using datastructure-def.xml 
to tell you what offsets and data types to use
- and then doing a lot of raw menmory writes
through void*s or the like.  
I prefer to generate the code because it is 
more portable, less likely to have 
portability problems like BigEndian vs. LittleEndian;
plus, not only is it safer code, but it is also
likely to be faster.






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]