OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Request for Discussion: SAX 1.0 in C++

[ Lists Home | Date Index | Thread Index ]
  • From: Steve Harris <seh@speakeasy.org>
  • To: xml-dev@ic.ac.uk
  • Date: 22 Dec 1999 09:40:11 -0800

Steinar Bang <sb@metis.no> writes:

> >>>>> Steve Harris <sharris@primus.com>:
> 
> > This UTF-8/UTF-16 representation translation seems like a job for
> > Standard C++'s <locale>/codecvt facility, not something to be
> > embedded in a string class.
> 
> Well, maybe... if the C++ standardarization commitee hadn't dropped
> the ball on sizeof(wchar_t)...:-/
> 
> I fear that this will make the entire std::wstring stuff unusable for
> multiplatform development.

[perhaps off-topic, but...]
Can you elaborate a bit here? Do you mean that the problem is that we
can't know the size of a wchar_t? Aren't there some guarantees to the
effect of, "A wchar_t will be at least as big as two chars," or
whatever would be appropriate? I can see how if you're writing the
low-level UTF-8 translation that you need to know what bits to shift
where. It seems that so long as the compiler will guarantee that you
can fit _at least_ 16 bits in a wchar_t, then your translation code
would be sufficiently portable.

[...]

> The MSVC++ Standard C++ Library support is seriously broken in a
> multitude of ways

[...]

Right. Do anything aggressive with templates and "Internal Compiler
Error" will become the stuff of nightmares.

I know we need to get work done today, but it's sad that we can't use
more of the Standard C++ pieces in a project like this. If we're
successful, this API will outlast the current rev of the lagging
compilers. I'm still in favor of planning an API that may not work for
everyone today. The C++ specification provides a road map (and
hopefully a guarantee) of where the compilers and libraries are going
to. We shouldn't have to ignore the generalized facilities that solve
our specific problem here. Targeting use of a fully-compliant
compiler/library pairing keeps us close to "The C++ Way," but I
concede that it may also keep us from using SAX in the near future.

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS