Boost logo

Boost :

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
*much* more...

Best regards,

Boost list run by bdawes at, gregod at, cpdaniel at, john at