From -4842205845899283832 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,35a35bec39c95517 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2001-03-26 12:04:07 PST Path: supernews.google.com!sn-xit-03!supernews.com!newsfeed.wirehub.nl!newspeer1.nac.net!colt.net!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: wchar & Unicode Date: Mon, 26 Mar 2001 20:02:07 GMT Organization: Mathematics Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: References: <3AB26307.A782192D@spamcop.net> <3AB2C76E.AA9DC137@wizard.net> <86zoej8aac.fsf@alex.gabi-soft.de> <864rwhbydb.fsf@alex.gabi-soft.de> X-Trace: mail2news.demon.co.uk 985636932 mail2news:29434 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: 26 Mar 2001 16:59:44 GMT Lines: 61 Xref: supernews.google.com comp.std.c++:4014 In article <864rwhbydb.fsf@alex.gabi-soft.de>, James Kanze wrote: >|> But if one uses say 32-bit wchar_t, writing 32-bit files, then each >|> wchar_t will first decomposed into bytes, and then picked together >|> to identical 32-bit words (assuming the OS can handle it). This is >|> slow: ... >All systems I know currently use byte oriented IO. In general, if you >want to write or read anything portably, you must read and write bytes. >Even if the actual data is 32 bits wide, you need to control the byte >order, for example. It depends: If the OS supports 32-bit file buffers, then it would not be convenient if the C++ requirement is to convert first into bytes. -- But perhaps it is possible to write a codesvt which directly calls the system routines in such a case. As for the interface between the computer parallel bus and the actual hard-disk, it may not make much difference, as it will be converted to whatever standard is used. >|> So it seems that for the future, one will need a mechanism for >|> reading and writing wider characters than char. (And it will >|> probably not be possible to let char be more than a byte for >|> backwards compatibility reasons.) > >If we ever do get OS's which really support reads and writes of more >than just bytes, we should give some thought as to how to support them. >For the moment, I don't think it's an issue. (For various reasons, I >doubt that it ever will be an issue.) The MacOS X, which should be publicly released by, already supports Unicode files. Perhaps it goes over bytes. But when Unicode becomes widespread, it seems likely that eventually 32-bit words at least will replace the byte concept altogether: There will simply be no reason to fiddle around with 8-bit bytes anymore. (In fact 64 bit bytes sound more reasonable, because one can fit a IEEE 64 bit float into that. Come back in a year perhaps and we will know, in view that computer capacity doubles every year. :-) ) >|> -- This reminds me that C++ does not appear to have a "save" command >|> for writing a file to disk. As file buffering is a common approach, >|> I think it would be prudent to add such a function. > >What is this save command supposed to do? It sounds an awful lot like >flush, from the little you say here. Right, I just forgot about flush; it will do. Hans Aberg * Anti-spam: remove "remove." from email address. * Email: Hans Aberg * Home Page: * AMS member listing: --- [ 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 ]