Cart
[Home] [By Thread] [By Date] [Recent Entries]
>> 2) We would prefer that all data come out of the SAX interfaces as >> raw wchar_t strings. This is the most flexible mechanism and does >> not lock people into using any particular implementation of a string >> object. It also has the highest potential performance for those >> folks who never need to put it into anything more formal than a raw >> array. > >std::basic_string<> _is_ a modern service of C++, and a pretty good >one from an API point of view. > >Personally I say: use std::basic_string<> and death to all other >string representations in C++. > 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. So either it has to be wchar_t or its left to the implementation how it will spit the stuff out. Of those two, wchar_t is the only one that will make this standard remotely standard. If everyone has to ignore the standard because it forces the use of stuff that they can't make use of, then its not much of a standard really and will just be a waste of time. Just my opinion of course... ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@u... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
