Request for Discussion: SAX 1.0 in C++
sb at metis.no
Tue Dec 14 08:54:41 GMT 1999
>>>>> roddey at us.ibm.com:
> 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 ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev