Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++ Subject: Re: How to get standard paths?!? Date: Sat, 17 Aug 2019 16:46:13 -0700 Organization: None to speak of Lines: 42 Message-ID: References: <_ZR5F.12655$hJ3.11614@fx07.am4> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="9783fc84761b29b85f300e9e166573f7"; logging-data="1691"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX194ghJvPS2x8/00ZlFtvJW0" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:fOA4yaSo1L/8YOgPF899Uiz0wXA= sha1:GZ60eASRdA8KWQU9x8rdYDgv//s= Xref: csiph.com comp.lang.c++:67720 David Brown writes: > On 17/08/2019 18:05, Bonita Montero wrote: >>> You can store any character encoding supported by the compiler in a >>> wchar_t, unless you are using Windows, which is broken and can't store >>> Unicode characters in a wchar_t because it is too small. >> >> The size of wchar_t is implementation-dependent, so Windows isn't broken >> here. > > Yes, Windows is broken here. The standards give minimum requirements > for many implementation-dependent features. Windows could have a 21-bit > wchar_t, or a 121-bit wchar_t if it liked, but not a 16-bit one. It is > just like saying the size of "int" is implementation dependent, but the > standards require a minimum of 16-bit int. **OR** it could have a 16-bit wchar_t and not claim to support Unicode as its wide character set. An implementation with 16-bit wchar_t that supports only the BMP as its wide character set could be conforming (though not as usesful as an implementation that supports full Unicode). But Microsoft's own documentation says: The wchar_t type is an implementation-defined wide character type. In the Microsoft compiler, it represents a 16-bit wide character used to store Unicode encoded as UTF-16LE, the native character type on Windows operating systems. The wide character versions of the Universal C Runtime (UCRT) library functions use wchar_t and its pointer and array types as parameters and return values, as do the wide character versions of the native Windows API. https://docs.microsoft.com/en-us/cpp/cpp/char-wchar-t-char16-t-char32-t?view=vs-2019 which I believe is non-conforming. (But I'm not sure how Microsoft could have fixed this without breaking too much existing code.) [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */