Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #67678 > unrolled thread

How to get standard paths?!?

Back to article view | Back to comp.lang.c++

Contents

  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 1 of 5  [1] 2 3 4 5  Next page →

#67678 — How to get standard paths?!?

Hello!

I am looking the best way to get system paths in Linux and Windows. 
Off-course the best will be portable way. Like this:
https://doc.qt.io/qt-5/qstandardpaths.html
But I don't want to use Qt. I want to write most of my app in pure C++.

I am looking for following paths:
std::wstring gSettingsDir();
std::wstring gLocalDataDir();
std::wstring gAppDataDir();
std::wstring gLogDir();
std::wstring gTempDir();

Can you give me some hints how to get them in Linux and Windows?!?


Thanks in advance and best regards!
Szyk Cech

[toc] | [next] | [standalone]

#67679

On 17.08.2019 13:58, Szyk Cech wrote:
> Hello!
> 
> I am looking the best way to get system paths in Linux and Windows. 
> Off-course the best will be portable way. Like this:
> https://doc.qt.io/qt-5/qstandardpaths.html
> But I don't want to use Qt. I want to write most of my app in pure C++.
> 
> I am looking for following paths:
> std::wstring gSettingsDir();
> std::wstring gLocalDataDir();
> std::wstring gAppDataDir();
> std::wstring gLogDir();
> std::wstring gTempDir();
> 
> Can you give me some hints how to get them in Linux and Windows?!?

In the previous posting you were enquiring about UTF-32 encoded wide 
strings.

Be advised that in Windows wide strings are UTF-16 encoded.


Cheers!,

- Alf

[toc] | [prev] | [next] | [standalone]

#67681

> 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.

[toc] | [prev] | [next] | [standalone]

#67683

On 17/08/2019 14:05, Bonita Montero wrote:
>> 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.

[toc] | [prev] | [next] | [standalone]

#67687

>>> 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.

[toc] | [prev] | [next] | [standalone]

#67688

On 17/08/2019 15:59, Bonita Montero wrote:
>>>> 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.

Again, you are assuming Windows is everything.

On most systems it is 32-bit.  The only exceptions I know are Windows, 
and a few 8-bit embedded targets.  (There may be others that I haven't 
tested, of course.)  On all *nix systems it is 32-bit, and on most 
embedded systems.

MS was early in the "Unicode" game by using UCS-2 in Windows NT.  They 
get credit for trying, IMHO.  But it quickly became apparent that 16 
bits was not sufficient, and anyone who was not tied to Windows used 
32-bit utf-32 when they needed "one object is one character", typically 
for internal use only, and utf-8 when they wanted strings.  If only MS 
had taken the hit and made the changes while they still could, it would 
have avoided the hideous mess that resulted with the painful 16-bit 
types.  16-bit is too short to hold all the Unicode characters, but long 
enough to have all the disadvantages of wasted space and endianness 
issues.  And now we are left with the jumble that is five different 
character types in C++ (not including signed and unsigned versions), MS' 
influence putting utf-16 nonsense into the C++ standards, and of course 
other platform-independent languages (Java, Python) and libraries (QT) 
using utf-16 or ucs-16 to be compatible with MS's error.

[toc] | [prev] | [next] | [standalone]

#67689

> MS was early in the "Unicode" game by using UCS-2 in Windows NT.  They 
> get credit for trying, IMHO.  But it quickly became apparent that 16 
> bits was not sufficient, and anyone who was not tied to Windows used 
> 32-bit utf-32 when they needed "one object is one character", typically 
> for internal use only, and utf-8 when they wanted strings.  If only MS 
> had taken the hit and made the changes while they still could, it would 
> have avoided the hideous mess that resulted with the painful 16-bit 
> types.  16-bit is too short to hold all the Unicode characters, but long 
> enough to have all the disadvantages of wasted space and endianness 
> issues.  And now we are left with the jumble that is five different 
> character types in C++ (not including signed and unsigned versions), MS' 
> influence putting utf-16 nonsense into the C++ standards, and of course 
> other platform-independent languages (Java, Python) and libraries (QT) 
> using utf-16 or ucs-16 to be compatible with MS's error.

We were not talking about UTF-whatever. We were talking about wchar_t
or more precisely std::u16sting. You can store 16 bit characters in the
latter as well as UTF-16-seqences in this.
We were talking about that you can almost rely on the fact that wchar_t
is 16 bits wide. There might be ancient CPU-architectures where the re-
gisters aren't 8, 16, ... bits wide but you can be certain that no one
would implement a conforming C++-compiler for these systems.

[toc] | [prev] | [next] | [standalone]

#67690

Am Sat, 17 Aug 2019 16:28:41 +0200
schrieb Bonita Montero <Bonita.Montero@gmail.com>:

> We were talking about that you can almost rely on the fact that
> wchar_t is 16 bits wide. There might be ancient CPU-architectures
> where the re- gisters aren't 8, 16, ... bits wide but you can be
> certain that no one would implement a conforming C++-compiler for
> these systems.


#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
…

[toc] | [prev] | [next] | [standalone]

#67691

> #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.

[toc] | [prev] | [next] | [standalone]

#67693

On 17.08.2019 17: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.

For once, I agree with you. Alas, Microsoft does not listen and still 
stubbornly clings to its unfortunate 16-bit Unicode representation, 
which is neither the most common (UTF-8 is) nor useful for easier text 
manipulation (UCS-32 is).

[toc] | [prev] | [next] | [standalone]

#67696

> For once, I agree with you. Alas, Microsoft does not listen and still 
> stubbornly clings to its unfortunate 16-bit Unicode representation, 
> which is neither the most common (UTF-8 is) nor useful for easier text 
> manipulation (UCS-32 is).

The APIs accepting UTF-16 strings aren't for persistence.
And there aren't any function for string-manipulation on
the Win32-API.

[toc] | [prev] | [next] | [standalone]

#67704

On 17.08.2019 18:54, Bonita Montero wrote:
>
> The APIs accepting UTF-16 strings aren't for persistence.

You mean, like CreateFileW() or RegSetKeyValueW()?

> And there aren't any function for string-manipulation on
> the Win32-API.

Like ExpandEnvironmentStringsW() or PathUnExpandEnvStringsW()?

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.

[toc] | [prev] | [next] | [standalone]

#67705

>> 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.

> 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.

[toc] | [prev] | [next] | [standalone]

#67706

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."

[toc] | [prev] | [next] | [standalone]

#67707

>> More precise: for persistent content.
>> And for both functions UTF-16 is sufficient.

> Sure, and UTF-8 would be as well.

UTF-8 and UTF-16 can adress 21 bits.
All codepoints that Unicode adresses.

> [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."
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^

[toc] | [prev] | [next] | [standalone]

#67709

On 17/08/2019 19:44, Bonita Montero wrote:
>>> More precise: for persistent content.
>>> And for both functions UTF-16 is sufficient.
> 
>> Sure, and UTF-8 would be as well.
> 
> UTF-8 and UTF-16 can adress 21 bits.
> All codepoints that Unicode adresses.
> 

Get back to use when you figure out how to fit 21 bits of Unicode code 
points into a 16-bit wchar_t.

You can happily store any Unicode characters in a UTF-16 string, but not 
in a single 16-bit character object.

>> [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."
>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 

[toc] | [prev] | [next] | [standalone]

#67732

> Get back to use when you figure out how to fit 21 bits of Unicode code 
> points into a 16-bit wchar_t.

wchar_t has no mandantory relationship to Unicode.
And Windows uses UTF-16. And UTF-16 works with 16 bit characters.

[toc] | [prev] | [next] | [standalone]

#67734

On 18/08/2019 07:58, Bonita Montero wrote:
>> Get back to use when you figure out how to fit 21 bits of Unicode code 
>> points into a 16-bit wchar_t.
> 
> wchar_t has no mandantory relationship to Unicode.
> And Windows uses UTF-16. And UTF-16 works with 16 bit characters.

This is what you might often do with ASCII:

    unsigned char ascii[128];
    for (i=0; i<128; ++i) ascii[i]=i;

So that all ascii code points are represented in sequence by each 
element of ascii;

What people are saying is that you can't do the equivalent for Unicode 
using Windows' wchar_t when the latter is 16 bits:

    unsigned wchar_t unicode[1114112];
    for (i=0; i<1114112; ++i) unicode[i]=i;

because the stored values will wrap back to 0 as soon as i gets to 65536 
(and again at 131072 and so on).

If this unicode[] array were to represent a UTF16 /string/, then its 
size would be greater than 1114112 elements, as many values require 
escape sequences with multiple elements, you couldn't write the loop in 
such a simple way, and you wouldn't have the Nth code point stored as 
the single value in unicode[N].

This is why a 32-bit wchar_t would have been a far better choice. 
Obviously, Windows can display and work with any Unicode characters, but 
it makes it more complicated than it would have been.

(There's nothing to stop a Windows program choosing to write the program 
like this:

    unsigned uint32_t unicode[1114112];
    for (i=0; i<1114112; ++i) unicode[i]=i;

but then such 32-bit characters, or strings using such arrays, are not 
directly supported by the OS.)

[toc] | [prev] | [next] | [standalone]

#67735

> If this unicode[] array were to represent a UTF16 /string/, then its 
> size would be greater than 1114112 elements, as many values require 
> escape sequences with multiple elements, you couldn't write the loop
> in such a simple way, and you wouldn't have the Nth code point stored
> as the single value in unicode[N].

Of course a wchar_t with 32 bits would be more convenient.
But with 16 bits its fits with Win32.
And the Uncicode-standard recommends UTF-16 fort certain circumstances.

>     unsigned uint32_t unicode[1114112];
>     for (i=0; i<1114112; ++i) unicode[i]=i;

No one uses char-arrays of that length in C++ but u16string
or u32string.

[toc] | [prev] | [next] | [standalone]

#67715

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.


     Bo Persson

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c++

csiph-web