Re: [lmi] Ledger::write() -- adding DOCTYPE support to xmlwrapp?

[Greg Chicares]

On 2008-12-10 22:36Z, Vaclav Slavik wrote:
> 
> this would be a good time to put more API-changing enhancements into
> xmlwrapp.

This comment in 'input_xml_io.cpp' may suggest a useful enhancement:

// XMLWRAPP !! The unit test demonstrates that the suppressed code is
// twenty-five percent slower. What would be really desirable is an
// (efficient) element-iterator class.

Let me try to explain what that's supposed to mean. A few lines below
that comment, we see:

    xml::node::const_iterator child;
    for(child = x.begin(); child != x.end(); ++child)
        {
[...]
        if(child->is_text())
            {
            continue;
            }

Skipping an iteration if iterator.is_text() is true seemed to be a
common idiom in the xmlwrapp sample programs. I looked into this
once, years ago, and IIRC it seemed that the iterator was accessing
data below the xml entity level. For example, again IIRC, given
  <foo>Hello</foo>
the iterator would reach "Hello". That's just my recollection, and
I might misunderstand it completely, but there's *some* reason why
that odd 'continue' idiom is needed.

Searching for is_text() in 'xml_lmi.cpp' finds some code that IIRC
was my attempt to encapsulate that idiom. And I think the comment
block quoted above means that my attempt proved too slow. So I
thought that perhaps an alternative iterator, which addresses only
full elements, could be a useful addition to xmlwrapp.

I hope that explanation makes more sense to you than it does to me.
I regret that I don't have time this year to figure this out well
enough to explain it clearly. The only thing I know for sure is
that I measured a 25% performance penalty as noted in that comment.

BTW, 'xml_lmi.?pp' doesn't have to live forever. It might be better
to kill it soon. Originally, it was only a way of unifying the
interfaces of two xml-wrapper libraries, libxml++ and xmlwrapp, so
that we could substitute one for the other safely. Then I looked at
the libxml++ internals and found them not to my taste. Maybe someday
someone'll develop an even better C++ library, in which case that
extra abstraction layer might be valuable; but I think that's very
unlikely. Otherwise, the extra abstraction is just confusing and
costly to maintain, and we should get rid of it someday and just
write to the xmlwrapp API directly. In particular, 'xml_lmi.?pp'
adds a lot of catch-diagnose-throw blocks that are probably useless
with xmlwrapp, but seemed important for libxml++ due to its poorer
robustness.