From 841917152932473804
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,b1fa62568eb1d2a7
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 2002-02-14 10:08:02 PST
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!dispose.news.demon.net!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail
From: remove.haberg@matematik.su.se (Hans Aberg)
Newsgroups: comp.std.c++
Subject: Re: Unicode vs. Char
Date: Thu, 14 Feb 2002 18:07:24 GMT
Organization: Mathematics
Approved: Fergus Henderson <fjh@cs.mu.oz.au>, moderator of comp.std.c++
Message-ID: <remove.haberg-1402021223270001@du130-226.ppp.su-anst.tninet.se>
References: <OEZ48.66846$h31.3769928@e420r-atl1.usenetserver.com> <remove.haberg-2801021229390001@du135-226.ppp.su-anst.tninet.se> <0hU68.89357$h31.5940930@e420r-atl1.usenetserver.com> <remove.haberg-0302021254480001@du128-226.ppp.su-anst.tninet.se> <a4be43$pga$1@news.mathworks.com> <remove.haberg-1302021239280001@du137-226.ppp.su-anst.tninet.se> <a4ecpf$oml@dispatch.concentric.net>
X-Trace: mail2news.demon.co.uk 1013710048 mail2news:8560 mail2news mail2news.demon.co.uk
X-Complaints-To: abuse@demon.net
X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au
X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f
X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov)
NNTP-Posting-Date: Thu, 14 Feb 2002 11:23:48 +0000 (UTC)
Lines: 37
Xref: archiver1.google.com comp.std.c++:9630

In article <a4ecpf$oml@dispatch.concentric.net>, "Ken Shaw"
<ken@_NO_SPAM_compinnovations.com> wrote:
>One very good reason for using UTF-8 is that legacy software will work if
>fed UTF-8 while most other encodings (any that allow a byte in the stream to
>have a value of 0) will cause those systems to fail.

Note that the C++ standard does not require "char" to have 8 bits.

But what will break with just using UTF-8 is operator++ and such, which
will not step to the next character, but to the next (C/C++) byte.

>I would be all in favor of requiring wchar_t to be 32 bits and requiring
>that the standard library include the appropriate UTF-8 to UTF-32 codecvt
>specializations. This would satisfy quite a lot of i18n needs without adding
>all the complexities of the ICU to the standard library.

And it might be good to not require such a requirement for wchar_t, as it
already may have other uses in compilers. (Some compilers already sets it
to 16 bits.)

Therefore, I think one should have a new type, perhaps named "unichar" or
"character" ("uchar" is often used as short for "unsigned char") which is
guaranteed to contain 32 bits internally.

For IO, one can add support for other encodings, like UTF-16, and UTF-8.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]



