Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c++ Subject: Re: How to get standard paths?!? Date: Sat, 17 Aug 2019 22:25:00 -0700 Organization: A noiseless patient Spider Lines: 52 Message-ID: <86y2zravv7.fsf@mailhub.linuxsc.com> References: <_ZR5F.12655$hJ3.11614@fx07.am4> <86blwnd534.fsf@mailhub.linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="938936979bf6115e9d0086b39ae6a6d8"; logging-data="27758"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/AIDGa3zMlMAiVsPb3njxFyCemFPb6jtU=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:F+WEus/clZmE5CQogBc9z3yNmuc= sha1:ULAAkhy7ZaCmxgD7M/AVhm+NZvU= Xref: csiph.com comp.lang.c++:67725 Bo Persson writes: > On 2019-08-17 at 20:22, Tim Rentsch wrote: > >> Bonita Montero writes: >> >>>>>> Be advised that in Windows wide strings are UTF-16 encoded. >>>>> >>>>> And I think that it would be the best to use std::u16string >>>>> because wchar_t is not absolutely guaranteed to be 16 bit >>>>> wide. >>>> >>>> It is guaranteed /not/ to be 16-bit on most systems. >>> >>> You can be pretty sure that by far most implementations specify >>> whcar_t as 16 bit since it makes no sense to implement it >>> differently. But it's easier to conform to any hypothetical >>> implementation by using char16_t. >> >> (and in another posting quotes the C++ standard) >> >>> "Type wchar_t is a distinct type whose values can represent >>> distinct codes for all members of the largest extended character >>> set specified among the supported locales (22.3.1)." >> >> Like you say, the C and C++ standards require wchar_t to be large >> enough so one wchar_t object can hold distinct values for every >> character in the largest supported character set. >> >> Most widely used operating systems today (eg, Microsoft Windows, >> Linux) support character sets with (at least) hundreds of >> thousands of characters. >> >> Can you explain how hundreds of thousands distinct values can be >> represented in a single 16-bit wide wchar_t object? > > No, they would naturally not fit. > > But there is a loop-hole here, as the language standard says "the > supported locales" and not "every existing locale". > > So if you only support the locales where 16 bits is enough, you > haven't broken any rules. And you cannot help is some people use > parts of "unsupported" locales as well... Perhaps not as much of a loophole as you think. The setlocale() function is defined, even for C++, by the C standard. A call to setlocale() must not accept a locale that has more characters than wchar_t can accommodate, because of how 'wide character' is defined. So the "unsupported" locales you are talking about cannot be used in a conforming implmentation. Of course, if the implementation is not conforming, it can do whatever it wants.