From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2003-06-02 08:57:13
Reece Dunn wrote:
>> That said, I would *not* recommend to rewrite any such thing. It is
>> a *lot* of work, and as such quite unrelated to boost's goals.
> Would also mapping an implementations structure to a C++ internal
> structure also require quite a bit of work?
yes ! As I said, parsing is only a small part of it all. Once you
hold a dom tree, you want to manipulate it. If the tree is implemented
in C++, all this, too, needs to be implemented anew.
What I did was to provide a *thin* wrapper around the internal C strucs
used by libxml2, so every dom manipulation call can be delegated down to
libxml2. For example xpath lookup: I call libxml2's xpath API, returning
me a C structure (possibly) holding a node set, i.e. a list of C
nodes. I just need to map these C structs back to my C++ wrapper objects
and I'm done with it. (Luckily for me, libxml2 provides all the hooks to
make that lookup very efficient...)
Imagine that with a C++ tree: You would trash the 'implementation
structure' as soon as the C++ structure is built, i.e. right after
the parsing is finished. So everything but parsing has to be rewritten
to fit your C++ data types.
> OPTION 2: If you are intending to wrap an implementation like libxml2
> into a C++ interface, you would sacrifice how the data is represented
> internally and you would get a slight performance penalty from the
> wrappers (not so much if you use inlined functions). This approach would
> not suffer the loading penalties described above.
Right, and it is what I chose. It's working wonderfully !
> OPTION 3: Writing a boost XML/XPath parser would allow the internal
> structure to be optimised for C++-specific bindings, while not suffering
> from either wrapper performance penalties nor document loading/SAX
> parsing penalties.
Well, that would mean to write 'yet another xml library'.
>> What I had (and still have) in mind is a C++ interface to an existing
>> implementation (libxml2 actually).
> What if the user wants an interface to another implementation? Is it
> possible to standardize access to other parsers.
good question. The API boost exposes should of course be independent.
But providing a different binding may practically be very hard, i.e.
require a lot of work. Again, don't focus on parsers only. There is