Request for Discussion: SAX 1.0 in C++

Steinar Bang sb at
Tue Dec 14 08:54:41 GMT 1999

>>>>> roddey at

> You are never going to win this argument. If you do try to force
> this, this 'standard' will die on the vine. As an example, and I'm
> speaking for me personally here, not IBM... I'm adding an XML parser
> to my CIDLib C++ libraries. There is zero chance that I'll use any
> standard library functionality in it, because the whole point of it
> is to not use the standard library, since its intended to (among
> many other things) replace the standard library with a much more
> powerful and integrated system. It gets high portability by having
> zero system or runtime headers show up outside of a very small core
> virtual kernel. Any standard which required me to use standard
> library stuff would be a non-starter, and I'd have no choice but to
> ignore it.

Then ignore it.

This seems a bit like the SML discussion.

Personally I think the Standard C++ Library is the way to go for all
C++ standardization in the future.  I'll strech to adapt to SAX' use
of the standard library, where my own build environments are lacking

If you want low overhead, there's always C, or your own SAX-like

Besides, in the particular environment you cite above, I don't think
you'd be able to achive parser plugability anyways, because
alternative parsers might need library features you don't support.

> So either it has to be wchar_t

It has to be SAXChar, actually, since wchar_t will be 32bit on some

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list