Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #67678 > unrolled thread
| Started by | Szyk Cech <szykcech@spoko.pl> |
|---|---|
| First post | 2019-08-17 13:58 +0200 |
| Last post | 2019-08-19 20:57 +0000 |
| Articles | 20 on this page of 84 — 15 participants |
Back to article view | Back to comp.lang.c++
How to get standard paths?!? Szyk Cech <szykcech@spoko.pl> - 2019-08-17 13:58 +0200
Re: How to get standard paths?!? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-17 14:02 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-17 14:05 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-17 15:11 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-17 15:59 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-17 16:20 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-17 16:28 +0200
Re: How to get standard paths?!? Ralf Goertz <me@myprovider.invalid> - 2019-08-17 16:37 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-17 16:54 +0200
Re: How to get standard paths?!? Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-17 18:37 +0300
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-17 17:54 +0200
Re: How to get standard paths?!? Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-17 19:55 +0300
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-17 19:15 +0200
Re: How to get standard paths?!? Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-17 20:39 +0300
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-17 19:44 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-17 20:10 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-18 08:58 +0200
Re: How to get standard paths?!? Bart <bc@freeuk.com> - 2019-08-18 10:16 +0100
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-18 11:27 +0200
Re: How to get standard paths?!? Bo Persson <bo@bo-persson.se> - 2019-08-17 21:07 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-17 21:41 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-17 17:40 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-17 17:52 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-17 18:00 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-17 18:01 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-17 18:26 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-17 20:20 +0200
Re: How to get standard paths?!? Keith Thompson <kst-u@mib.org> - 2019-08-17 16:33 -0700
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-18 11:34 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-18 08:48 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-18 11:34 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-18 12:57 +0200
Re: How to get standard paths?!? Bart <bc@freeuk.com> - 2019-08-18 13:07 +0100
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-18 15:49 +0200
Re: How to get standard paths?!? Bo Persson <bo@bo-persson.se> - 2019-08-18 20:33 +0200
Re: How to get standard paths?!? Bart <bc@freeuk.com> - 2019-08-18 20:51 +0100
Re: How to get standard paths?!? Bo Persson <bo@bo-persson.se> - 2019-08-19 00:04 +0200
Re: How to get standard paths?!? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-25 05:35 -0700
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-25 15:02 +0200
Re: How to get standard paths?!? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-25 06:38 -0700
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-25 15:46 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-25 15:54 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-19 08:52 +0200
Re: How to get standard paths?!? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-19 09:32 +0200
Re: How to get standard paths?!? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-22 12:37 -0700
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-19 10:26 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-17 18:00 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-17 18:06 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-17 20:24 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-18 08:49 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-18 11:46 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-18 12:59 +0200
Re: How to get standard paths?!? scott@slp53.sl.home (Scott Lurndal) - 2019-08-18 15:40 +0000
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-18 17:44 +0200
Re: How to get standard paths?!? scott@slp53.sl.home (Scott Lurndal) - 2019-08-18 15:38 +0000
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-18 17:46 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-17 17:56 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-17 18:05 +0200
Re: How to get standard paths?!? Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2019-08-17 19:47 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-17 20:46 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-18 08:54 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-18 12:07 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-18 13:05 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-18 14:48 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-18 15:51 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-18 16:43 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-18 17:02 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-17 20:41 +0200
Re: How to get standard paths?!? Keith Thompson <kst-u@mib.org> - 2019-08-17 16:46 -0700
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-18 12:22 +0200
Re: How to get standard paths?!? Robert Wessel <robertwessel2@yahoo.com> - 2019-08-17 22:57 -0500
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-18 08:57 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-18 12:24 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-18 13:07 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-18 13:13 +0200
Re: How to get standard paths?!? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-17 11:22 -0700
Re: How to get standard paths?!? Bo Persson <bo@bo-persson.se> - 2019-08-17 21:21 +0200
Re: How to get standard paths?!? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-17 22:25 -0700
Re: How to get standard paths?!? Robert Wessel <robertwessel2@yahoo.com> - 2019-08-19 01:19 -0500
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-19 08:25 +0200
Re: How to get standard paths?!? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-17 14:02 +0200
Re: How to get standard paths?!? David Brown <david.brown@hesbynett.no> - 2019-08-17 15:13 +0200
Re: How to get standard paths?!? Sam <sam@email-scan.com> - 2019-08-17 09:21 -0400
Re: How to get standard paths?!? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-08-19 20:57 +0000
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-17 21:41 +0200 |
| Message-ID | <qj9l9j$6ev$1@dont-email.me> |
| In reply to | #67715 |
On 17/08/2019 21:07, Bo Persson wrote: > On 2019-08-17 at 19:39, Paavo Helde wrote: >> On 17.08.2019 20:15, Bonita Montero wrote: >>>>> The APIs accepting UTF-16 strings aren't for persistence. >>> >>>> You mean, like CreateFileW() or RegSetKeyValueW()? >>> >>> More precise: for persistent content. >>> And for both functions UTF-16 is sufficient. >> >> Sure, and UTF-8 would be as well. >> >>> >>>> Not that it would matter the slightest. Microsoft's use of wchar_t >>>> still does not match the C++ standard and UTF-16 still remains the >>>> most useless Unicode representation. >>> >>> wchar_t is not required to be 32 bit wide. >> >> Sure, wchar_t can be 64 bit or whatever as long as it can hold any >> character supported by the implementation [1]. Windows happens to >> support Unicode, so a 16-bit type does not cut it. >> >> [1] 3.9.1/5: "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." >> > > And, of course, MS follows the letter of the law here by limiting the > number of supported locales. The language standard says nothing about that. > I can understand if MS Windows does not support Cuneiform or Old Persian locales. But are you telling me they don't support Chinese, Japanese or Korean using plane 2 characters? My understanding is that the standard Windows API's for things like file names now support full UTF-16 encodings, and that includes characters that won't fit in a 16-bit wchar_t. When the decision to have 16-bit wchar_t was made, these API's were UCS-2, so 16-bit wchar_t was a suitable and complaint choice at that time. But it is not suitable any more (and hasn't been for a long time).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-17 17:40 +0200 |
| Message-ID | <qj9756$kvg$1@dont-email.me> |
| In reply to | #67691 |
On 17/08/2019 16:54, Bonita Montero wrote:
>> #include <iostream>
>>
>> int main() {
>> std::cout<<sizeof(wchar_t)<<std::endl;
>> }
>>
>>> g++ -o wchar wchar.cc
>>> ./wchar
>> 4
>>> g++ -v
>> Using built-in specs.
>> COLLECT_GCC=g++
>> COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/9/lto-wrapper
>> OFFLOAD_TARGET_NAMES=hsa:nvptx-none
>> Target: x86_64-suse-linux
>> …
>
> Hard, I wouldn't have expected this. I think this isn't a clever
> decision. For internal processing the representation doesn't matter
> but for compatiblity-reasons it should match the most commun Unicode
> representation.
How about reading what others post, and perhaps /thinking/ a little? In
particular, get out of the "the world is Windows" mindset.
wchar_t has /never/ been specifically about Unicode. It means "wide
character", it is supposed to big enough to hold a character of any
character set supported by the implementation. For example, a Chinese
system might support ASCII and Big5, which is a 16-bit encoding - it
could therefore have a 16-bit wchar_t.
For systems that support Unicode, wchar_t is required to be at least
32-bit. That is why it /is/ 32-bit on any modern system - except broken
Windows where wchar_t is not as big as the C++ standards require. The
common case of 16-bit wchar_t in Windows compilers is in fact not
standard C++.
As for the "most common Unicode representation", for files or data
interchange, that is UTF-8 by many orders of magnitude. UTF-16 and
UTF-32 are found in a few niche situations. Internally, within
programs, UTF-32 is sometimes used (mostly by people who think it is
important to be able to index characters or count characters really
quickly). It is the standard wchar_t type, used by most systems.
Within Windows, you can't avoid UTF-16 internally and for API calls -
and it is also used by people who mistakenly think one wchar_t
represents one code point. And UTF-16 is also used by some libraries,
such as QT, that are stuck with it for historical reasons.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-17 17:52 +0200 |
| Message-ID | <qj97sh$4fp$1@news.albasani.net> |
| In reply to | #67694 |
> wchar_t has /never/ been specifically about Unicode. It means "wide > character", it is supposed to big enough to hold a character of any > character set supported by the implementation. For example, a Chinese > system might support ASCII and Big5, which is a 16-bit encoding - it > could therefore have a 16-bit wchar_t. Unrealistic that it will be used for anything different than Unicode. > For systems that support Unicode, wchar_t is required to be at least > 32-bit. No, it's implementation-defined.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-17 18:00 +0200 |
| Message-ID | <qj98a0$57i$1@news.albasani.net> |
| In reply to | #67695 |
>> For systems that support Unicode, wchar_t is required to be at least >> 32-bit. > No, it's implementation-defined. That is what the standard says about that: "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). Type wchar_t shall have the same size, signedness, and alignment requirements (3.11) as one of the other integral types, called its underlying type."
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-17 18:01 +0200 |
| Message-ID | <qj98cq$ric$2@dont-email.me> |
| In reply to | #67698 |
On 17/08/2019 18:00, Bonita Montero wrote: >>> For systems that support Unicode, wchar_t is required to be at least >>> 32-bit. > >> No, it's implementation-defined. > > That is what the standard says about that: > > "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). Type wchar_t shall have the same > size, signedness, and alignment requirements (3.11) as one of the other > integral types, called its underlying type." Exactly, yes. 16-bit wchar_t can't do that on a system that supports Unicode (regardless of the encoding).
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-17 18:26 +0200 |
| Message-ID | <qj99s4$k3$1@news.albasani.net> |
| In reply to | #67700 |
> Exactly, yes. 16-bit wchar_t can't do that on a system that > supports Unicode (regardless of the encoding). There will be no more Unicode codepoints populated than could be adressed by UTF-16. At least until we gonna support alien languages.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-17 20:20 +0200 |
| Message-ID | <qj9gi7$bea$1@dont-email.me> |
| In reply to | #67703 |
On 17/08/2019 18:26, Bonita Montero wrote: >> Exactly, yes. 16-bit wchar_t can't do that on a system that >> supports Unicode (regardless of the encoding). > > There will be no more Unicode codepoints populated than could be > adressed by UTF-16. At least until we gonna support alien languages. Does your ignorance know no bounds? Aren't you even capable of the simplest of web searches or references before talking rubbish in public? <https://en.wikipedia.org/wiki/Unicode> <https://home.unicode.org/> Currently, Unicode has 137,929 characters. These are organised in different 32 code planes of 64K characters, of which only 3 code planes are significantly used. But 3 planes is a great deal more than 1 plane - 16-bit has been insufficient for Unicode since 1996.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-08-17 16:33 -0700 |
| Message-ID | <ln1rxj5puh.fsf@kst-u.example.com> |
| In reply to | #67710 |
David Brown <david.brown@hesbynett.no> writes:
> On 17/08/2019 18:26, Bonita Montero wrote:
>>> Exactly, yes. 16-bit wchar_t can't do that on a system that
>>> supports Unicode (regardless of the encoding).
>>
>> There will be no more Unicode codepoints populated than could be
>> adressed by UTF-16. At least until we gonna support alien languages.
>
> Does your ignorance know no bounds?
>
> Aren't you even capable of the simplest of web searches or references
> before talking rubbish in public?
I think you have incorrectly assumed that Bonita is asserting that there
are no more than 65536 Unicode codepoints.
UTF-16 can represent all Unicode codepoints. It cannot represent each
Unicode codepoint in 16 bits; some of them require two 16-bit values.
I presume Bonita meant that UTF-16 can represent all of Unicode (which
is true). But a 16-bit wchar_t cannot, because the standard requires
wchar_t to be "able to represent all members of the execution
wide-character set" (that's the point Bonita missed or ignored).
To use wchar_t to represent all Unicode code points, you either have to
make wchar_t at least 21 bits (more likely 32 bits) *or* you have to use
it in a way that doesn't satisfy the requirements of the standard, such
as using UTF-16 to encode some characters in more than one wchar_t.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-18 11:34 +0200 |
| Message-ID | <qjb62q$4u7$1@dont-email.me> |
| In reply to | #67719 |
On 18/08/2019 01:33, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 17/08/2019 18:26, Bonita Montero wrote: >>>> Exactly, yes. 16-bit wchar_t can't do that on a system that >>>> supports Unicode (regardless of the encoding). >>> >>> There will be no more Unicode codepoints populated than could be >>> adressed by UTF-16. At least until we gonna support alien languages. >> >> Does your ignorance know no bounds? >> >> Aren't you even capable of the simplest of web searches or references >> before talking rubbish in public? > > I think you have incorrectly assumed that Bonita is asserting that there > are no more than 65536 Unicode codepoints. Possibly. If I have misinterpreted her, then I will be glad to be corrected. > > UTF-16 can represent all Unicode codepoints. It cannot represent each > Unicode codepoint in 16 bits; some of them require two 16-bit values. Correct - and that is something I have said several times. > > I presume Bonita meant that UTF-16 can represent all of Unicode (which > is true). But a 16-bit wchar_t cannot, because the standard requires > wchar_t to be "able to represent all members of the execution > wide-character set" (that's the point Bonita missed or ignored). Agreed - and again, it is something I have said several times. It is fine (both in the sense of working practically and in being compliant with the standards) to use char16_t and u16string to handle all Unicode strings and characters. You can't store all Unicode characters in a /single/ char16_t object - but a char16_t is for storing Unicode code /units/, not code /points/, so it is fine for the job. But a whcar_t has to be able to store any /character/ - for Unicode, that means 21 bits of code point. > > To use wchar_t to represent all Unicode code points, you either have to > make wchar_t at least 21 bits (more likely 32 bits) *or* you have to use > it in a way that doesn't satisfy the requirements of the standard, such > as using UTF-16 to encode some characters in more than one wchar_t. > In practice, I think people on Windows use wchar_t strings (or arrays) for holding UTF-16 encoding strings. That will work fine. But it encourages mistaken assumptions - such as that ws[9] holds the tenth Unicode character in the string, or that wcslen returns the number of characters in the string. These assumptions hold for a proper wchar_t, such as the 32-bit wchar_t on Unix systems (or a 16-bit wchar_t on Windows while it used UCS-2 rather than UTF-16). I think the sensible practice would be to deprecate the use of wchar_t as much as possible, using instead char8_t for UTF-8 strings when dealing with string data (and especially for data interchange), and char32_t for UTF-32 encoding internally if you need character-by-character access. These are unambiguous and function identically across platforms (except perhaps for the endianness of char32_t). For interaction with legacy code and API's on Windows, char16_t is a better choice than wchar_t. Going forward, C++ could drop wchar_t and support for wide character execution sets other than Unicode, just as it is dropping support for signed integer representations other than two's complement. This kind of thing limits flexibility in theory, but not in practice, and it would simplify things a bit.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-18 08:48 +0200 |
| Message-ID | <qjasc4$2o1$1@news.albasani.net> |
| In reply to | #67710 |
> Does your ignorance know no bounds? Unicode is defined to have a maximum of 21 bit codepoints.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-18 11:34 +0200 |
| Message-ID | <qjb63k$4u7$2@dont-email.me> |
| In reply to | #67727 |
On 18/08/2019 08:48, Bonita Montero wrote: >> Does your ignorance know no bounds? > > Unicode is defined to have a maximum of 21 bit codepoints. > Yes. And how to you fit those 21 bits into a 16-bit wchar_t ?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-18 12:57 +0200 |
| Message-ID | <qjbav1$uap$1@news.albasani.net> |
| In reply to | #67737 |
>> Unicode is defined to have a maximum of 21 bit codepoints. > Yes. And how to you fit those 21 bits into a 16-bit wchar_t ? That's not necessary if you use UTF-16.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-08-18 13:07 +0100 |
| Message-ID | <7cb6F.89442$GfB1.45648@fx36.am4> |
| In reply to | #67743 |
On 18/08/2019 11:57, Bonita Montero wrote:
>>> Unicode is defined to have a maximum of 21 bit codepoints.
>
>> Yes. And how to you fit those 21 bits into a 16-bit wchar_t ?
>
> That's not necessary if you use UTF-16.
>
Show me how to make use of UTF-16 here, because it doesn't seem to work
on Windows:
#include <wchar_t>
wchar_t c;
c = 1000000; // character code 1000000
printf("c = %d 0x%X", c, c);
Displays:
c = 16960 0x4240
Not this:
c = 1000000 0xF4240
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-18 15:49 +0200 |
| Message-ID | <qjbl1n$7eo$1@news.albasani.net> |
| In reply to | #67748 |
> Show me how to make use of UTF-16 here, because it doesn't seem to work
> on Windows:
>
> #include <wchar_t>
>
> wchar_t c;
> c = 1000000; // character code 1000000
>
> printf("c = %d 0x%X", c, c);
>
> Displays:
>
> c = 16960 0x4240
>
> Not this:
>
> c = 1000000 0xF4240
wchar_t needs not to be Unicode-compliant.
But you can store UTF16-strings in std::wstring.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2019-08-18 20:33 +0200 |
| Message-ID | <grtk07Fcnh9U1@mid.individual.net> |
| In reply to | #67748 |
On 2019-08-18 at 14:07, Bart wrote:
> On 18/08/2019 11:57, Bonita Montero wrote:
>>>> Unicode is defined to have a maximum of 21 bit codepoints.
>>
>>> Yes. And how to you fit those 21 bits into a 16-bit wchar_t ?
>>
>> That's not necessary if you use UTF-16.
>>
>
>
> Show me how to make use of UTF-16 here, because it doesn't seem to work
> on Windows:
>
> #include <wchar_t>
>
> wchar_t c;
> c = 1000000; // character code 1000000
>
> printf("c = %d 0x%X", c, c);
>
> Displays:
>
> c = 16960 0x4240
>
> Not this:
>
> c = 1000000 0xF4240
So we can only guess that this character code is not part of the
"supported locale" used in your program.
Nowhere does the language standard require C++ to support all available
OS locales. It could be a very small subset.
Bo Persson
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-08-18 20:51 +0100 |
| Message-ID | <r%h6F.22023$Jh2.12734@fx39.am4> |
| In reply to | #67765 |
On 18/08/2019 19:33, Bo Persson wrote:
> On 2019-08-18 at 14:07, Bart wrote:
>> On 18/08/2019 11:57, Bonita Montero wrote:
>>>>> Unicode is defined to have a maximum of 21 bit codepoints.
>>>
>>>> Yes. And how to you fit those 21 bits into a 16-bit wchar_t ?
>>>
>>> That's not necessary if you use UTF-16.
>>>
>>
>>
>> Show me how to make use of UTF-16 here, because it doesn't seem to
>> work on Windows:
>>
>> #include <wchar_t>
>>
>> wchar_t c;
>> c = 1000000; // character code 1000000
>>
>> printf("c = %d 0x%X", c, c);
>>
>> Displays:
>>
>> c = 16960 0x4240
>>
>> Not this:
>>
>> c = 1000000 0xF4240
>
> So we can only guess that this character code is not part of the
> "supported locale" used in your program.
>
> Nowhere does the language standard require C++ to support all available
> OS locales. It could be a very small subset.
A small subset where none of the locale's alphabets has character codes
above 65535.
Anyway, the locale need have nothing to do with the ability to be able
to read, write or process arbitrary Unicode characters and strings.
Otherwise countries such as the UK and US could get by with just ASCII.
But if they are going beyond a 7-bit character, then why not beyond
16-bit too? Actually, the first few alphabets beyond codepoint 65535
appear to be ancient scripts with no meaningful locale anyway.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2019-08-19 00:04 +0200 |
| Message-ID | <gru0b4Ff9p7U1@mid.individual.net> |
| In reply to | #67766 |
On 2019-08-18 at 21:51, Bart wrote:
> On 18/08/2019 19:33, Bo Persson wrote:
>> On 2019-08-18 at 14:07, Bart wrote:
>>> On 18/08/2019 11:57, Bonita Montero wrote:
>>>>>> Unicode is defined to have a maximum of 21 bit codepoints.
>>>>
>>>>> Yes. And how to you fit those 21 bits into a 16-bit wchar_t ?
>>>>
>>>> That's not necessary if you use UTF-16.
>>>>
>>>
>>>
>>> Show me how to make use of UTF-16 here, because it doesn't seem to
>>> work on Windows:
>>>
>>> #include <wchar_t>
>>>
>>> wchar_t c;
>>> c = 1000000; // character code 1000000
>>>
>>> printf("c = %d 0x%X", c, c);
>>>
>>> Displays:
>>>
>>> c = 16960 0x4240
>>>
>>> Not this:
>>>
>>> c = 1000000 0xF4240
>>
>> So we can only guess that this character code is not part of the
>> "supported locale" used in your program.
>>
>> Nowhere does the language standard require C++ to support all
>> available OS locales. It could be a very small subset.
>
> A small subset where none of the locale's alphabets has character codes
> above 65535.
Yes, that would conform to the C++ standard.
>
> Anyway, the locale need have nothing to do with the ability to be able
> to read, write or process arbitrary Unicode characters and strings.
Neither does wchar_t. The C++ standard only says:
"The values of type wchar_t can represent distinct codes for all members
of the largest extended character set specified among the supported
locales."
And then it is up to the implementation to define what locales that
could be.
>
> Otherwise countries such as the UK and US could get by with just ASCII.
>
> But if they are going beyond a 7-bit character, then why not beyond
> 16-bit too? Actually, the first few alphabets beyond codepoint 65535
> appear to be ancient scripts with no meaningful locale anyway.
VC++ also offers non-standard use of UTF-16, should you need to use
those characters anyway. But that is an extension, and not standard C++.
This is kind of similar to some compilers allowing the use of integer
types larger that intmax_t, by calling __int128 an extension (and not
"an extended integer type").
Bo Persson
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-08-25 05:35 -0700 |
| Message-ID | <868srh1kyz.fsf@mailhub.linuxsc.com> |
| In reply to | #67771 |
Bo Persson <bo@bo-persson.se> writes:
> On 2019-08-18 at 21:51, Bart wrote:
>
>> On 18/08/2019 19:33, Bo Persson wrote:
>>
>>> On 2019-08-18 at 14:07, Bart wrote:
>>>
>>>> On 18/08/2019 11:57, Bonita Montero wrote:
>>>>
>>>>>>> Unicode is defined to have a maximum of 21 bit codepoints.
>>>>>>
>>>>>> Yes. And how to you fit those 21 bits into a 16-bit wchar_t ?
>>>>>
>>>>> That's not necessary if you use UTF-16.
>>>>
>>>> Show me how to make use of UTF-16 here, because it doesn't seem to
>>>> work on Windows:
>>>>
>>>> #include <wchar_t>
>>>>
>>>> wchar_t c;
>>>> c = 1000000; // character code 1000000
>>>>
>>>> printf("c = %d 0x%X", c, c);
>>>>
>>>> Displays:
>>>>
>>>> c = 16960 0x4240
>>>>
>>>> Not this:
>>>>
>>>> c = 1000000 0xF4240
>>>
>>> So we can only guess that this character code is not part of the
>>> "supported locale" used in your program.
>>>
>>> Nowhere does the language standard require C++ to support all
>>> available OS locales. It could be a very small subset.
>>
>> A small subset where none of the locale's alphabets has character
>> codes above 65535.
>
> Yes, that would conform to the C++ standard.
>
>> Anyway, the locale need have nothing to do with the ability to be
>> able to read, write or process arbitrary Unicode characters and
>> strings.
>
> Neither does wchar_t. The C++ standard only says:
>
> "The values of type wchar_t can represent distinct codes for all
> members of the largest extended character set specified among the
> supported locales."
>
> And then it is up to the implementation to define what locales that
> could be.
>
>> Otherwise countries such as the UK and US could get by with just ASCII.
>>
>> But if they are going beyond a 7-bit character, then why not beyond
>> 16-bit too? Actually, the first few alphabets beyond codepoint 65535
>> appear to be ancient scripts with no meaningful locale anyway.
>
> VC++ also offers non-standard use of UTF-16, should you need to use
> those characters anyway. But that is an extension, and not standard
> C++.
>
> This is kind of similar to some compilers allowing the use of integer
> types larger that intmax_t, by calling __int128 an extension (and not
> "an extended integer type").
I see you are giving the same wrong arguments that you gave three
years ago.
C and C++ implementations must support the locale-specific native
environment (assuming a hosted implementation in C). They don't
get to choose what that is; they are required to document it,
but the standards do not AFAICT give any freedom to choose it. If
the native environment in MS Windows has more than 65K characters
then the implementation is non-conforming.
Besides that, regardless of what locale names are documented as
being "supported", any locale whose name is accepted by the
setlocale() function (ie, return value is not null) must have the
property that all of its characters have distinct values that fit
in a single wchar_t object. Any violation of this property means
the implementation is not conforming. Note that the setlocale()
calls all fall within the bounds of Standard-specified behavior.
There is no wiggle room available to try to sweep these under the
rug as "extensions".
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-25 15:02 +0200 |
| Message-ID | <qju0tp$gi2$1@news.albasani.net> |
| In reply to | #67937 |
> C and C++ implementations must support the locale-specific native > environment (assuming a hosted implementation in C). They don't > get to choose what that is; they are required to document it, > but the standards do not AFAICT give any freedom to choose it. > If the native environment in MS Windows has more than 65K characters > then the implementation is non-conforming. Quote the part of the C++-standard that says this.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-08-25 06:38 -0700 |
| Message-ID | <864l251i1p.fsf@mailhub.linuxsc.com> |
| In reply to | #67938 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >> C and C++ implementations must support the locale-specific native >> environment (assuming a hosted implementation in C). They don't >> get to choose what that is; they are required to document it, >> but the standards do not AFAICT give any freedom to choose it. >> If the native environment in MS Windows has more than 65K characters >> then the implementation is non-conforming. > > Quote the part of the C++-standard that says this. In N4659: Section 25.5.1 p1: "The contents and meaning of the header <clocale> are the same as the C standard library header <locale.h>." Section 2 (Normative references) p2: "The library described in Clause 7 of ISO/IEC 9899:2011 is hereinafter called the /C standard library/."
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web