From 6909710509660035287 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fc772,5d41e81747468e0d X-Google-Attributes: gidfc772,public X-Google-Thread: f78e5,b1fa62568eb1d2a7,start X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-02-01 14:42:05 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!news-out.cwix.com!newsfeed.cwix.com!feed.news.qwest.net!namche.sun.com!news2me.EBay.Sun.COM!engnews1.eng.sun.com!taumet!clamage From: remove.haberg@matematik.su.se (Hans Aberg) Newsgroups: comp.std.c++,comp.lang.c++.moderated Subject: Re: Unicode vs. Char Followup-To: comp.std.c++ Date: 1 Feb 2002 22:20:49 GMT Organization: Mathematics Lines: 73 Approved: stephen.clamage@sun.com (comp.std.c++) Message-ID: References: NNTP-Posting-Host: taumet.eng.sun.com X-NNTP-Posting-Host: netlab.cs.rpi.edu X-Original-Date: Mon, 28 Jan 2002 12:29:39 +0100 X-Submission-Address: c++-submit@netlab.cs.rpi.edu X-Auth: PGPMoose V1.1 PGP comp.lang.c++.moderated iQBVAwUAPFVN4kHMCo9UcraBAQFWrAH9Ew4O6+HbthrXZZ6HxZAQXvGFv21GIYEp 4NVSU5z+KQiFmWR6UYVrbSou4g6BAWFfguj4gjnKJiuozzSciUzqzQ== =zcqf X-Approved-For-Group: hsutter@acm.org comp.lang.c++.moderated X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Content-Length: 3660 X-Status: $$$$ X-UID: 0000000001 Originator: clamage@taumet Xref: archiver1.google.com comp.std.c++:9355 comp.lang.c++.moderated:36445 [Please note that follow-ups are set to comp.std.c++.] In article , "Early Ehlinger" wrote: >A recent thread that started out discussing why basic_ofstream has no >constructor taking a wchar_t* quickly changed into a discussion of >whether wchar_t was defined by the Standard to be a Unicode character. >From there, the discussion went to whether the Standard should make >such a definition... >Proposal: ... >In C++0x and C0x as well, deprecate char, char* and any variant >thereof. (!!!) In its place, we would add two new types, _character_t >and _byte_t. All functions returning or accepting strings or >characters would be deprecated as well, and replaced with versions >returning/accepting _character_t. This kind of questions have been discussed in comp.std.c++. In brief (and perhaps follow-ups will say that I am wrong): The C/C++ standards are written so that one can never ensure, in a compiler independent manner, what the underlying binary (bit structure) is. Clearly, if now C++0x (see first article with this subject title in comp.std.c++ last year) is supposed to support distributed programming, that attitude will not hold, as one then exchanges binary objects between programs that may have been compiled with different compilers. As for the C/C++ byte, the allocation "atom", it has in the past in (in the context of C) sometimes have had say 9 bits on some platforms; my compilers indicates a platform where it is 16 bits. It is not possible to deprecate "char", because almost all code would break. But one may think of introducing new types that do rely on a special type of binary representation: A byte type with exactly 8 bits, and say a type "unichar", encoding probably UTF-32, with additional macros telling if the compiler can support them. (Some say that the presence of these types may create overheads they do not want to have.) One should note that the Unicode character numbers do not rely on any binary computer representation. So it might be possible to merely specify that a unichar should be able to hold all Unicode characters, with UTF-32 and other translations being present. I think though that it is going to be very complicated to use variable width characters internally in a program (and slow, due to alignment cutoffs that the CPU will have to perform), so that suggests one should use UTF-32 and nothing else. There is also the high/low "endian" issue when dealing with Unicode representations. This probably belongs to the distributed programming chapter. One model that comes to my mind in order to resolve this problem is to number all bits in the computer (instead of words), and specify the representation with respect to that. In this model, the high/low endian representations are two different encodings in this binary model. Hans Aberg * Anti-spam: remove "remove." from email address. * Email: Hans Aberg * Home Page: * AMS member listing: [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ] [ 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 ] [ Note that the FAQ URL has changed! Please update your bookmarks. ]