On Thursday 09 March 2006 13:57, Scott Cantor wrote:
> > > But I gave up trying to hide XMLCh from my code. That's my native
> > > character type until I hit a boundary I can't avoid.
> >
> > My primary use for the DOM is a means of serialization and
> > de-serialization of my runtime objects.
>
> Me too, in some sense, but my runtime objects use XMLCh as their native
> string form by design. I understand that's often completely impossible, but
> in those cases, it's painful.
>
> FWIW, I think libxml2 uses 8-bit characters (UTF-8 I'd imagine) as its
> basic interface. Maybe that would suit you better?
QDom would work just fine for my immediate purposes. AFAIK, Xerces is the
most complete, W3C "conforming" (whatever that means in C++) DOM
implementation. There was a time when I was getting pretty good at Xerces-J.
I've found Xerces-C much more difficult to learn. Grant it, I was fairly new
to C++ when I originally looked at it. I suspect that once I get past the
inconveniences such as tracing through the #include labyrinth for the
#defines, knowing what part of the API matters to the user, and accept the
fact that XMLCh is what it is, Xerces should prove fairly easy to use.
I've learned a lot from this discussion. I now have a much grater
appreciation for the difficulties of working with UTF, and a much grater
appreciation for Qt's ease of use and power where I need it.
This is sweet:
const XMLCh* QtoX(const QString& s) { return s.utf16(); }
QString XtoQ(const XMLCh* x) { return QString::fromUtf16(x); }
BTW, if I don't like a software product, I don't complain about it, I ignore
it.
Steven
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
