[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

• From: Steve Harris <seh@s...>
• To: xml-dev@i...
• Date: 22 Dec 1999 09:40:11 -0800

Steinar Bang <sb@m...> writes:

> >>>>> Steve Harris <sharris@p...>:
> 
> > 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@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...)

• Follow-Ups:
  • Re: Request for Discussion: SAX 1.0 in C++
    • From: Steinar Bang <sb@m...>
  • Re: Request for Discussion: SAX 1.0 in C++
    • From: Steinar Bang <sb@m...>

• References:
  • Re: Request for Discussion: SAX 1.0 in C++
    • From: Steve Harris <sharris@p...>
  • Re: Request for Discussion: SAX 1.0 in C++
    • From: Steinar Bang <sb@m...>

• Prev by Date: RE: SAX2: DeclHandler
• Next by Date: xlink, xinclude, show, and actuate
• Previous by thread: Re: Request for Discussion: SAX 1.0 in C++
• Next by thread: Re: Request for Discussion: SAX 1.0 in C++
• Index(es):
  • Date
  • Thread