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

Groups > comp.lang.c > #92880 > unrolled thread

"Unicode"

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

Contents

  "Unicode" Lynn McGuire <lynnmcguire5@gmail.com> - 2016-08-29 12:06 -0500
    Re: "Unicode" Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-01 21:54 +0100
      Re: "Unicode" raltbos@xs4all.nl (Richard Bos) - 2016-09-03 08:00 +0000
        Re: "Unicode" Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-03 14:10 -0500
          Re: "Unicode" "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2016-09-04 09:56 +0200
            Re: "Unicode" Paavo Helde <myfirstname@osa.pri.ee> - 2016-09-04 14:37 +0300
              Re: "Unicode" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-04 23:57 -0700
              Re: "Unicode" "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2016-09-05 12:53 +0200
                Re: "Unicode" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-05 04:51 -0700
                Re: "Unicode" Paavo Helde <myfirstname@osa.pri.ee> - 2016-09-05 15:30 +0300
                  Re: "Unicode" "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2016-09-05 16:13 +0200
                    Re: "Unicode" Paavo Helde <myfirstname@osa.pri.ee> - 2016-09-05 22:03 +0300
                      Re: "Unicode" "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2016-09-05 23:54 +0200
                        Re: "Unicode" Keith Thompson <kst-u@mib.org> - 2016-09-05 15:35 -0700
                          Re: "Unicode" "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2016-09-06 00:18 +0200
                            Re: "Unicode" Keith Thompson <kst-u@mib.org> - 2016-09-05 16:17 -0700
                              Re: "Unicode" "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2016-09-06 01:20 +0200
                                Re: "Unicode" Keith Thompson <kst-u@mib.org> - 2016-09-05 17:16 -0700
                                  Re: "Unicode" "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2016-09-06 02:42 +0200
                              Re: "Unicode" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-05 17:07 -0700
                        Re: "Unicode" Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-05 23:05 +0100
            Re: "Unicode" Vir Campestris <vir.campestris@invalid.invalid> - 2016-09-04 21:37 +0100
              Re: "Unicode" Paavo Helde <myfirstname@osa.pri.ee> - 2016-09-05 00:22 +0300
                Re: "Unicode" Vir Campestris <vir.campestris@invalid.invalid> - 2016-09-05 21:32 +0100
                  Re: "Unicode" Paavo Helde <myfirstname@osa.pri.ee> - 2016-09-06 00:00 +0300
                    Re: "Unicode" Vir Campestris <vir.campestris@invalid.invalid> - 2016-09-07 21:19 +0100
                      Re: "Unicode" "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2016-09-08 02:16 +0200

Page 1 of 2  [1] 2  Next page →

#92880 — "Unicode"

"Unicode"
    http://xkcd.com/1726/

"Watching the Unicode people try to govern the infinite chaos of human language with consistent technical standards is like watching 
highway engineers try to steer a river using traffic signs."

As usual, Randall Munroe nails it.

Lynn

[toc] | [next] | [standalone]

#93080

On 29/08/2016 18:06, Lynn McGuire wrote:
> "Unicode"
>    http://xkcd.com/1726/
>
> "Watching the Unicode people try to govern the infinite chaos of human
> language with consistent technical standards is like watching highway
> engineers try to steer a river using traffic signs."
>
> As usual, Randall Munroe nails it.

Unicode is simple in C++: just use std::string and UTF-8.

/Flibble

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

#93149

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote:

> On 29/08/2016 18:06, Lynn McGuire wrote:
> > "Unicode"
> >    http://xkcd.com/1726/
> >
> > "Watching the Unicode people try to govern the infinite chaos of human
> > language with consistent technical standards is like watching highway
> > engineers try to steer a river using traffic signs."
> >
> > As usual, Randall Munroe nails it.
> 
> Unicode is simple in C++: just use std::string and UTF-8.

You... do not understand Unicode.

If you think the problem is just one of choosing one correct charset,
you're very naive. The problems are much hairier than that, and much
more detailed.

Richard

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

#93160

Richard Bos <raltbos@xs4all.nl> wrote:
> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote:
> 
>> On 29/08/2016 18:06, Lynn McGuire wrote:
>>> "Unicode"
>>> http://xkcd.com/1726/
>>> 
>>> "Watching the Unicode people try to govern the infinite chaos of human
>>> language with consistent technical standards is like watching highway
>>> engineers try to steer a river using traffic signs."
>>> 
>>> As usual, Randall Munroe nails it.
>> 
>> Unicode is simple in C++: just use std::string and UTF-8.
> 
> You... do not understand Unicode.
> 
> If you think the problem is just one of choosing one correct charset,
> you're very naive. The problems are much hairier than that, and much
> more detailed.

Of course I understand Unicode: I am designing a compliant text editor
widget as I write this.  As far as C++ is concerned it really is that
simple.

/Flibble 

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

#93187

On 03.09.2016 21:10, Mr Flibble wrote:
> Richard Bos <raltbos@xs4all.nl> wrote:
>> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote:
>>
>>> On 29/08/2016 18:06, Lynn McGuire wrote:
>>>> "Unicode"
>>>> http://xkcd.com/1726/
>>>>
>>>> "Watching the Unicode people try to govern the infinite chaos of human
>>>> language with consistent technical standards is like watching highway
>>>> engineers try to steer a river using traffic signs."
>>>>
>>>> As usual, Randall Munroe nails it.
>>>
>>> Unicode is simple in C++: just use std::string and UTF-8.
>>
>> You... do not understand Unicode.
>>
>> If you think the problem is just one of choosing one correct charset,
>> you're very naive. The problems are much hairier than that, and much
>> more detailed.
>
> Of course I understand Unicode: I am designing a compliant text editor
> widget as I write this.  As far as C++ is concerned it really is that
> simple.

The common C and C++ standard libraries in Windows, as well as the 
Windows `char` based API functions, expect Windows ANSI encoding.

Which is not one single encoding but depends on the system.

That's a good reason for portable code to Just Say No to other encodings 
for plain `char` text, than the C++ execution character set.

In *nix-land it's easier, since the C++ execution character set is 
typically Unicode encoded as UTF-8, and since that can be part of the C 
locale.

In Windows it can't.


Cheers & hth.,

- Alf

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

#93190

On 4.09.2016 10:56, Alf P. Steinbach wrote:
> On 03.09.2016 21:10, Mr Flibble wrote:
>> Richard Bos <raltbos@xs4all.nl> wrote:
>>> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote:
>>>
>>>> On 29/08/2016 18:06, Lynn McGuire wrote:
>>>>> "Unicode"
>>>>> http://xkcd.com/1726/
>>>>>
>>>>> "Watching the Unicode people try to govern the infinite chaos of human
>>>>> language with consistent technical standards is like watching highway
>>>>> engineers try to steer a river using traffic signs."
>>>>>
>>>>> As usual, Randall Munroe nails it.
>>>>
>>>> Unicode is simple in C++: just use std::string and UTF-8.
>>>
>>> You... do not understand Unicode.
>>>
>>> If you think the problem is just one of choosing one correct charset,
>>> you're very naive. The problems are much hairier than that, and much
>>> more detailed.
>>
>> Of course I understand Unicode: I am designing a compliant text editor
>> widget as I write this.  As far as C++ is concerned it really is that
>> simple.
>
> The common C and C++ standard libraries in Windows, as well as the
> Windows `char` based API functions, expect Windows ANSI encoding.

That's why you never use Windows 'char' based API functions.

> Which is not one single encoding but depends on the system.
>
> That's a good reason for portable code to Just Say No to other encodings
> for plain `char` text, than the C++ execution character set.
>
> In *nix-land it's easier, since the C++ execution character set is
> typically Unicode encoded as UTF-8, and since that can be part of the C
> locale.
>
> In Windows it can't.

No, you can perfectly well use UTF-8 based strings in Windows, I have 
done this for 15 years. You just define a couple of convenience 
functions for easy conversion to-from UTF-16 at the application border 
(or to-from any other encoding when calling a library which expects 
another encoding).

Cheers
Paavo

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

#93209

On Sunday, September 4, 2016 at 12:38:11 PM UTC+1, Paavo Helde wrote:
> 
> No, you can perfectly well use UTF-8 based strings in Windows, I have 
> done this for 15 years. You just define a couple of convenience 
> functions for easy conversion to-from UTF-16 at the application border 
> (or to-from any other encoding when calling a library which expects 
> another encoding).
> 
Exactly.

I'm also considering adding a UTF-8 text stream writer. This will open
any file, and convert between UTF-8 and file native encoding, and back.
Then we'll deprecate the write operation, to prevent any more non-
UTF-8 text files coming into the world.

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

#93221

On 04.09.2016 13:37, Paavo Helde wrote:
> On 4.09.2016 10:56, Alf P. Steinbach wrote:
>>
>> In *nix-land it's easier, since the C++ execution character set is
>> typically Unicode encoded as UTF-8, and since that can be part of the C
>> locale.
>>
>> In Windows it can't.
>
> No, you can perfectly well use UTF-8 based strings in Windows,

It can't be part of the C locale.

That's like, period.


> I have done this for 15 years.

No you haven't.

You may have used UTF-8 in your programs in Windows, as you can on any 
platform, for 15 years. That's something else. It's not practical when 
quality is important, but that's a very different discussion.

You have not used UTF-8 C locales in Windows.


> You just define a couple of convenience
> functions for easy conversion to-from UTF-16 at the application border
> (or to-from any other encoding when calling a library which expects
> another encoding).

Well, I'm sorry to say this, but that code probably have some severe 
limitations on filenames etc.

Generally, code originating in the *nix world, or based on such 
software, fares badly in Windows. For example, filenames and paths for 
Open CV library. Not to mention for the Code Blocks IDE.

I wouldn't mind the limitation to pure ASCII so much if they just could 
add support for spaces, for Pete's sake. It's like something from the 
dark ages. Or before.


Cheers,

- Alf

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

#93222

On Monday, September 5, 2016 at 11:53:59 AM UTC+1, Alf P. Steinbach wrote:
> On 04.09.2016 13:37, Paavo Helde wrote:
>
> You may have used UTF-8 in your programs in Windows, as you can on any 
> platform, for 15 years. That's something else. It's not practical when 
> quality is important, but that's a very different discussion.
> 
> You have not used UTF-8 C locales in Windows.
> 
> 
The idea is pretty sound.
Pass everything about as UTF-8, until you hit an API that demands character data
in a different format. Then convert. I'm sure there are snags, however. What
if the characters sets don't contain the characters you need? What if the conversion
functions cannot be written because the information as to what character set the
not-UTF8 system is using is not available, or it's unfeasible to write because it
means coding in arbitrary maps with thousands of entries?
>
> > You just define a couple of convenience
> > functions for easy conversion to-from UTF-16 at the application border
> > (or to-from any other encoding when calling a library which expects
> > another encoding).
> 
> Well, I'm sorry to say this, but that code probably have some severe 
> limitations on filenames etc.
> 
> Generally, code originating in the *nix world, or based on such 
> software, fares badly in Windows. For example, filenames and paths for 
> Open CV library. Not to mention for the Code Blocks IDE.
> 
> I wouldn't mind the limitation to pure ASCII so much if they just could 
> add support for spaces, for Pete's sake. It's like something from the 
> dark ages. Or before.
> 
I agree.
Someone decided it was a good idea to present "My Documents" as a 
"folder", to the user and broke every script that didn't insist on quoting 
file paths. Now you never know whether quotes are forbidden, mandatory, 
or optional - I end up running utilities like CMake with different inputs
just to find out.
To be fair there was some issue with copyright that banned MS from using
normal path separators in the olden days. Millions and millions of dollars
worth of economic damage inflicted by that one on us from the legal boys.
So the whole thing was badly designed from day one.

But OpenCV is a sophisticated image processing and recognition library.
For it to break just because of trivia with filenames and string representation
is totally unacceptable. The community must find a way round this sort
of thing.

I'm doing my best with Baby X.

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

#93223

On 5.09.2016 13:53, Alf P. Steinbach wrote:
> On 04.09.2016 13:37, Paavo Helde wrote:
>> On 4.09.2016 10:56, Alf P. Steinbach wrote:
>>>
>>> In *nix-land it's easier, since the C++ execution character set is
>>> typically Unicode encoded as UTF-8, and since that can be part of the C
>>> locale.
>>>
>>> In Windows it can't.
>>
>> No, you can perfectly well use UTF-8 based strings in Windows,
>
> It can't be part of the C locale.
>
> That's like, period.
>
>
>> I have done this for 15 years.
>
> No you haven't.
>
> You may have used UTF-8 in your programs in Windows, as you can on any
> platform, for 15 years. That's something else. It's not practical when
> quality is important, but that's a very different discussion.
>
> You have not used UTF-8 C locales in Windows.

I have not claimed that. And it would not work anyway because as I wrote 
everything is converted to UTF-16 at the app border by the app itself, 
so using a UTF-8 locale would be very wrong.

All this locale stuff is pretty evil anyway (as every other hidden 
global state). Our code always uses either explicit "C" locale via 
functions like strtod_l() or enforces "C" locale otherwise. By using 
locale-dependent functions the functionality of the program would become 
unpredictable and very hard to maintain. The clear negative example is 
Excel where you can never know what punctuation you must enter in a 
formula because the syntax is heavily locale-dependent, and copy-pasting 
a piece of CSV most often does not work correctly.

Using locales might be useful only in the immediate user interface, and 
even there it is often more misleading or irritating than useful (e.g. 
random pieces of local language in long-formatted dates, in an otherwise 
correct English text). If you call that 'quality', then I humbly beg to 
differ.

Fortunately enough, most of my work is not related to UI and any 
locale-sensitivity is considered as a bug, not a feature.

>
>> You just define a couple of convenience
>> functions for easy conversion to-from UTF-16 at the application border
>> (or to-from any other encoding when calling a library which expects
>> another encoding).
>
> Well, I'm sorry to say this, but that code probably have some severe
> limitations on filenames etc.

Care to bring some examples? As far as I know, there is 1:1 translation 
from UTF-8 to UTF-16 used by Windows SDK file functions. It's true that 
not all Unix world filenames like those containing colons or backslashes 
are supported by Windows, but this has nothing to do with UTF-8.

>
> Generally, code originating in the *nix world, or based on such
> software, fares badly in Windows. For example, filenames and paths for
> Open CV library. Not to mention for the Code Blocks IDE.
>
> I wouldn't mind the limitation to pure ASCII so much if they just could
> add support for spaces, for Pete's sake. It's like something from the
> dark ages. Or before.

Sorry, here you lost me. Windows has supported spaces in filenames for 
20 years already. Probably you are talking about something else.

Cheers
Paavo

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

#93224

On 05.09.2016 14:30, Paavo Helde wrote:
> On 5.09.2016 13:53, Alf P. Steinbach wrote:
>> On 04.09.2016 13:37, Paavo Helde wrote:
>>> On 4.09.2016 10:56, Alf P. Steinbach wrote:
>>>>
>>>> In *nix-land it's easier, since the C++ execution character set is
>>>> typically Unicode encoded as UTF-8, and since that can be part of the C
>>>> locale.
>>>>
>>>> In Windows it can't.
>>>
>>> No, you can perfectly well use UTF-8 based strings in Windows,
>>
>> It can't be part of the C locale.
>>
>> That's like, period.
>>
>>
>>> I have done this for 15 years.
>>
>> No you haven't.
>>
>> You may have used UTF-8 in your programs in Windows, as you can on any
>> platform, for 15 years. That's something else. It's not practical when
>> quality is important, but that's a very different discussion.
>>
>> You have not used UTF-8 C locales in Windows.
>
> I have not claimed that.

Well, in context your "no" indicated a claim in that direction.

Except for context the "no" could mean anything, really.

It seems now that you meant a much wider context than just the preceding 
paragraph or two, but that was not obvious to me, sorry.


> And it would not work anyway because as I wrote
> everything is converted to UTF-16 at the app border by the app itself,
> so using a UTF-8 locale would be very wrong.
>
> All this locale stuff is pretty evil anyway (as every other hidden
> global state). Our code always uses either explicit "C" locale via
> functions like strtod_l() or enforces "C" locale otherwise. By using
> locale-dependent functions the functionality of the program would become
> unpredictable and very hard to maintain.

Oh, mostly I agree with that sentiment.

Still,

• A host of C standard library functions are locale dependent.

• Even C++ wide streams are locale dependent. In particular they don't 
work in *nix-land unless you set the locale, e.g. `setlocale( LC_ALL, "" 
)` in `main`. That's because they translate to/from external.

• Even string comparison, uppercasing and lowercasing in Unicode is to 
some degree locale dependent. However, I've always ignored that 
subtlety. I think, to the degree it's a problem one should just leave it 
to the users to deal properly with it, e.g. by avoiding troublesome 
¹Turkish or whatever characters.


> The clear negative example is
> Excel where you can never know what punctuation you must enter in a
> formula because the syntax is heavily locale-dependent, and copy-pasting
> a piece of CSV most often does not work correctly.

Yeah, agree, the Excel team/managers were insane.

They even at some point tried to provide national language versions of 
the scripting language, making not just CSV files but also scripts, 
effectively non-portable.


> Using locales might be useful only in the immediate user interface, and
> even there it is often more misleading or irritating than useful (e.g.
> random pieces of local language in long-formatted dates, in an otherwise
> correct English text). If you call that 'quality', then I humbly beg to
> differ.

By [lack of] "quality" I was referring to e.g. the common restriction to 
plain ASCII for *nix based code such as Open CV, lack of reliable 
support for spaces in paths such as in Code Blocks, lack of support for 
the backspace key such as in an installer for Qt at one point (I didn't 
know whether to laugh or cry), and so on, and on, and forth.


> Fortunately enough, most of my work is not related to UI and any
> locale-sensitivity is considered as a bug, not a feature.
>
>>
>>> You just define a couple of convenience
>>> functions for easy conversion to-from UTF-16 at the application border
>>> (or to-from any other encoding when calling a library which expects
>>> another encoding).
>>
>> Well, I'm sorry to say this, but that code probably have some severe
>> limitations on filenames etc.
>
> Care to bring some examples?

std::ofstream f( utf8_file_path ); //  OK in *nix, ungood in Windows.



> As far as I know, there is 1:1 translation
> from UTF-8 to UTF-16 used by Windows SDK file functions. It's true that
> not all Unix world filenames like those containing colons or backslashes
> are supported by Windows, but this has nothing to do with UTF-8.

Windows uses the colon as a stream name separator.

<example>
[c:\my\forums\clc++\036]
 > echo bah >knurre.txt:comment

[c:\my\forums\clc++\036]
 > dir | find "knurre.txt"
05.09.2016  16:07                 0 knurre.txt

[c:\my\forums\clc++\036]
 > more <knurre.txt:comment
bah

[c:\my\forums\clc++\036]
 > _
</example>

General *nix filenames /can/ be handled in an app, but the easiest then 
is to instead is to use whatever they now have instead of Interix 
subsystem for Unix.


>> Generally, code originating in the *nix world, or based on such
>> software, fares badly in Windows. For example, filenames and paths for
>> Open CV library. Not to mention for the Code Blocks IDE.
>>
>> I wouldn't mind the limitation to pure ASCII so much if they just could
>> add support for spaces, for Pete's sake. It's like something from the
>> dark ages. Or before.
>
> Sorry, here you lost me. Windows has supported spaces in filenames for
> 20 years already. Probably you are talking about something else.

Context. I'm talking about, quote from immediately preceding paragraph, 
"code originating in the *nix world, or based on such software, fares 
badly in Windows. For example, filenames and paths for Open CV library. 
Not to mention for the Code Blocks IDE."

E.g. last I tried it, Code Blocks still couldn't handle spaces in paths 
in general.

I think using UTF-8 encoding internally in a program in Windows can be 
OK for some special application domains, when that reduces porting work. 
Presumably the code you've been working on has been such.


Cheers!,

- Alf

Notes:
¹ See e.g. <url: http://www.i18nguy.com/unicode/turkish-i18n.html>

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

#93231

On 5.09.2016 17:13, Alf P. Steinbach wrote:
> On 05.09.2016 14:30, Paavo Helde wrote:
>> On 5.09.2016 13:53, Alf P. Steinbach wrote:
>>> On 04.09.2016 13:37, Paavo Helde wrote:
>>>> You just define a couple of convenience
>>>> functions for easy conversion to-from UTF-16 at the application border
>>>> (or to-from any other encoding when calling a library which expects
>>>> another encoding).
>>>
>>> Well, I'm sorry to say this, but that code probably have some severe
>>> limitations on filenames etc.
>>
>> Care to bring some examples?
>
> std::ofstream f( utf8_file_path ); //  OK in *nix, ungood in Windows.

Just tested this in Windows and it created the expected file ('(c) 
abc.txt') nicely.

#include <string>
#include <iostream>
#include <fstream>

#ifdef _WIN32
typedef std::wstring ExternalString;
#else
typedef std::string ExternalString;
#endif

/// Convert from UTF-8 to external platform-specific encoding
ExternalString ToExt(const std::string& utf8string);

int main() {

	std::string filename_utf8 = "C:\\temp\\\xC2\xA9 abc.txt";

	std::ofstream f(ToExt(filename_utf8).c_str());

}

#ifdef _WIN32
#include <Windows.h>

ExternalString ToExt(const std::string& utf8string) {
	ExternalString result(utf8string.length(), 0);
	if (!utf8string.empty()) {
		int n = MultiByteToWideChar(CP_UTF8, 0, utf8string.data(), 
utf8string.length(), &result[0], result.length());
		// Error check omitted for brevity
		result.resize(n);
	}
	return result;
}

#else

ExternalString ToExt(const std::string& utf8string) {
	return utf8string;
}
#endif

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

#93235

On 05.09.2016 21:03, Paavo Helde wrote:
> On 5.09.2016 17:13, Alf P. Steinbach wrote:
>> On 05.09.2016 14:30, Paavo Helde wrote:
>>> On 5.09.2016 13:53, Alf P. Steinbach wrote:
>>>> On 04.09.2016 13:37, Paavo Helde wrote:
>>>>> You just define a couple of convenience
>>>>> functions for easy conversion to-from UTF-16 at the application border
>>>>> (or to-from any other encoding when calling a library which expects
>>>>> another encoding).
>>>>
>>>> Well, I'm sorry to say this, but that code probably have some severe
>>>> limitations on filenames etc.
>>>
>>> Care to bring some examples?
>>
>> std::ofstream f( utf8_file_path ); //  OK in *nix, ungood in Windows.
>
> Just tested this in Windows and it created the expected
> file ('(c) abc.txt') nicely.

No, you tested with an UTF-16 file path, of type std::wstring.

That wide string std::ofstream constructor is a Microsoft extension, 
although it will effectively be required for Windows implementations of 
C++ by the filesystem library of C++17.

As a result the code fails to compile with e.g. g++ 5.1.0.

     • • •

Most (all?) g++ distros for Windows default to UTF-8 as the C++ 
execution character set. So ideally one could just use the narrow string 
directly for g++, i.e., a little compiler dependency, that's not a large 
cost. Unfortunately in Windows the default g++ standard library 
implementations expect Windows ANSI, i.e. incompatible with the 
compiler's C++ execution character set, and there's no way to change the 
locale to an UTF-8 one.

     • • •

The system dependent ExternalString string in your code, wide in Windows 
and narrow elsewhere, is IMO a good idea, though. I've advocated it for 
long, although I call it System_string. With proper support it can be 
used to handle text /internally/ in a program, avoiding all the problems 
with incompatibility between the internal representation and the 
standard library, OS API etc., and avoiding most of the gross 
inefficiencies, like dynamic allocations, of conversions to/from.

That proper support isn't trivial, though.

It includes e.g. a fix for the g++ problem noted above.


Cheers & hth.,

- Alf

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

#93236

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
[...]
> Most (all?) g++ distros for Windows default to UTF-8 as the C++ 
> execution character set. So ideally one could just use the narrow string 
> directly for g++, i.e., a little compiler dependency, that's not a large 
> cost. Unfortunately in Windows the default g++ standard library 
> implementations expect Windows ANSI, i.e. incompatible with the 
> compiler's C++ execution character set, and there's no way to change the 
> locale to an UTF-8 one.

"ANSI" is an incorrect name for the Windows-1252 8-bit character set
(and related code pages).  Even Microsoft no longer calls it that.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#93238

On 06.09.2016 00:35, Keith Thompson wrote:
> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
> [...]
>> Most (all?) g++ distros for Windows default to UTF-8 as the C++
>> execution character set. So ideally one could just use the narrow string
>> directly for g++, i.e., a little compiler dependency, that's not a large
>> cost. Unfortunately in Windows the default g++ standard library
>> implementations expect Windows ANSI, i.e. incompatible with the
>> compiler's C++ execution character set, and there's no way to change the
>> locale to an UTF-8 one.
>
> "ANSI" is an incorrect name for the Windows-1252 8-bit character set
> (and related code pages).  Even Microsoft no longer calls it that.

“Windows ANSI” is not a name for a specific character set.

It's the codepage specified by the ¹GetACP API function, which, not very 
well documented, is the codepage specified in the <registry: 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage> key, 
item name ACP, which is short for “ANSI code page”.

The information you have about deprecation of the name “ANSI” may well 
be correct. Microsoft has, after all, deprecated nearly all of the 
original string functions of the C library. That is, they believed they 
had: but it was, just like an attempted deprecation of the name used in 
their APIs, documentation, books etc., just utter nonsense. :)


Cheers & hth.,

- Alf

¹ Documented at <url: 
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318070(v=vs.85).aspx>

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

#93239

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
> On 06.09.2016 00:35, Keith Thompson wrote:
[...]
>> "ANSI" is an incorrect name for the Windows-1252 8-bit character set
>> (and related code pages).  Even Microsoft no longer calls it that.
>
> “Windows ANSI” is not a name for a specific character set.
>
> It's the codepage specified by the ¹GetACP API function, which, not very 
> well documented, is the codepage specified in the <registry: 
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage> key, 
> item name ACP, which is short for “ANSI code page”.

ACP may originally have been an abbreviation of "ANSI Code Page", and
apparently it's still used as a key name for backward compatibility
(which sounds reasonable).

My point is that "Windows ANSI" is a misnomer.  The character sets in
question were intended to be an ANSI standard(s), but they were never
approved.  The collection of code pages sometimes referred to as
"Windows ANSI" have nothing to do with the American National Standards
Institute.

> The information you have about deprecation of the name “ANSI” may well 
> be correct. Microsoft has, after all, deprecated nearly all of the 
> original string functions of the C library. That is, they believed they 
> had: but it was, just like an attempted deprecation of the name used in 
> their APIs, documentation, books etc., just utter nonsense. :)

That's not quite the same.  Microsoft's attempt to deprecate the
standard string functions is absurd, since they're still in the ISO C
standard.  Deprecating the name "ANSI" for certain Windows-specific
character sets, on the other hand, is entirely reasonable.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#93240

On 06.09.2016 01:17, Keith Thompson wrote:
> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>> On 06.09.2016 00:35, Keith Thompson wrote:
> [...]
>>> "ANSI" is an incorrect name for the Windows-1252 8-bit character set
>>> (and related code pages).  Even Microsoft no longer calls it that.
>>
>> “Windows ANSI” is not a name for a specific character set.
>>
>> It's the codepage specified by the ¹GetACP API function, which, not very
>> well documented, is the codepage specified in the <registry:
>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage> key,
>> item name ACP, which is short for “ANSI code page”.
>
> ACP may originally have been an abbreviation of "ANSI Code Page", and
> apparently it's still used as a key name for backward compatibility
> (which sounds reasonable).
>
> My point is that "Windows ANSI" is a misnomer.

In that, you're right.

But I have not written or implied it's not.

Please provide a quote to back up that implied assertion.


>  The character sets in question were intended to be an ANSI standard(s),

No.

Windows ANSI Western, codepage 1252, was based on a draft of ISO 
Latin-1, then, as I recall, developed in cooperation between the ANSI 
institute in America, and its French counterpart.

It was not intended to an ANSI standard: it was possibly intended to be 
one-way compatible with the ANSI standard ISO Latin-1, since it is a 
strict superset.

Regarding the other Windows ANSI character sets they include e.g. Shift 
JIS, which has almost no relation to Windows ANSI Western.

I believe some of them are ANSI and ISO standards, but maybe not.


> but they were never approved.

Please provide evidence that they were submitted for standardization.


>  The collection of code pages sometimes referred to as
> "Windows ANSI" have nothing to do with the American National Standards
> Institute.

In that, you're right.

But I have not written or implied the opposite.

I think you're just trying to associate with me with the silly notions 
that you APPEAR to be arguing against.

If so then that's not very honest argumentation.


>> The information you have about deprecation of the name “ANSI” may well
>> be correct. Microsoft has, after all, deprecated nearly all of the
>> original string functions of the C library. That is, they believed they
>> had: but it was, just like an attempted deprecation of the name used in
>> their APIs, documentation, books etc., just utter nonsense. :)
>
> That's not quite the same.

Oh, it is. Microsoft do things that are technically nonsense, apparently 
focusing on vendor lock-in (giving rise to the ¹EEE acronym: Embrace, 
Extend and Extinguish) and on social issues such as, in this case (if 
you're right about it), in-group terminology. In the case of the 
attempted deprecation of C library functions it was linked to an 
in-group terminology and an in-group set of annotation and checking 
tools, that maybe have some value in C but just are a hassle in C++.


>  Microsoft's attempt to deprecate the
> standard string functions is absurd, since they're still in the ISO C
> standard.  Deprecating the name "ANSI" for certain Windows-specific
> character sets, on the other hand, is entirely reasonable.

No, that's also incorrect.

E.g. check the documentation of Windows' GetACP function, which I linked to.

It's not “entirely resonable” to change a term that's hardwired into API 
functions, documentation, books, ²Wikipedia, etc. ad nauseam.


Cheers & hth.,

- Alf

¹ https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
² https://en.wikipedia.org/wiki/Windows_code_page#ANSI_code_page

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

#93241

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
> On 06.09.2016 01:17, Keith Thompson wrote:
[...]
>> My point is that "Windows ANSI" is a misnomer.
>
> In that, you're right.
>
> But I have not written or implied it's not.

You use the phrase without pointing out that it's incorrect.

> Please provide a quote to back up that implied assertion.

From upthread:

    Unfortunately in Windows the default g++ standard library
    implementations expect Windows ANSI, i.e. incompatible with the
    compiler's C++ execution character set, and there's no way to
    change the locale to an UTF-8 one.

>>  The character sets in question were intended to be an ANSI standard(s),
>
> No.
>
> Windows ANSI Western, codepage 1252, was based on a draft of ISO 
> Latin-1, then, as I recall, developed in cooperation between the ANSI 
> institute in America, and its French counterpart.
>
> It was not intended to an ANSI standard: it was possibly intended to be 
> one-way compatible with the ANSI standard ISO Latin-1, since it is a 
> strict superset.
>
> Regarding the other Windows ANSI character sets they include e.g. Shift 
> JIS, which has almost no relation to Windows ANSI Western.
>
> I believe some of them are ANSI and ISO standards, but maybe not.
>
>
>> but they were never approved.
>
> Please provide evidence that they were submitted for standardization.

Quoting https://en.wikipedia.org/wiki/Windows_code_page#ANSI_code_page :

    ANSI Windows code pages, and especially the code page 1252,
    were called that way since they were purportedly based on drafts
    submitted or intended for ANSI. However, ANSI and ISO have not
    standardized any of these code pages.

My statement seems to have been imprecise.

>>  The collection of code pages sometimes referred to as
>> "Windows ANSI" have nothing to do with the American National Standards
>> Institute.
>
> In that, you're right.
>
> But I have not written or implied the opposite.
>
> I think you're just trying to associate with me with the silly notions 
> that you APPEAR to be arguing against.
>
> If so then that's not very honest argumentation.

I think you're overreacting to my criticism.  You referred to "Windows
ANSI".  There's really no such thing, though it's a common misuse.

[snip]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#93246

On 06.09.2016 02:16, Keith Thompson wrote:
> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>> On 06.09.2016 01:17, Keith Thompson wrote:
> [...]
>>> My point is that "Windows ANSI" is a misnomer.
>>
>> In that, you're right.
>>
>> But I have not written or implied it's not.
>
> You use the phrase without pointing out that it's incorrect.

No, the term “Windows ANSI” is not incorrect at all: it's the name of 
this concept. You can read all about it in Microsoft's documentation 
(which I linked to) and in Wikipedia (which I linked to). It's a 
misnomer when it's (foolishly) treated as a descriptive term, and it is 
the name of this concept.



>> Please provide a quote to back up that implied assertion.
>
> From upthread:
>
>     Unfortunately in Windows the default g++ standard library
>     implementations expect Windows ANSI, i.e. incompatible with the
>     compiler's C++ execution character set, and there's no way to
>     change the locale to an UTF-8 one.

So, where in that quote is the argument that you're arguing against?

Again, I perceive your argumentation as merely a way to throw out 
negative associations.

You'd have to work pretty hard to convince me otherwise.


>>>  The character sets in question were intended to be an ANSI standard(s),
>>
>> No.
>>
>> Windows ANSI Western, codepage 1252, was based on a draft of ISO
>> Latin-1, then, as I recall, developed in cooperation between the ANSI
>> institute in America, and its French counterpart.
>>
>> It was not intended to an ANSI standard: it was possibly intended to be
>> one-way compatible with the ANSI standard ISO Latin-1, since it is a
>> strict superset.
>>
>> Regarding the other Windows ANSI character sets they include e.g. Shift
>> JIS, which has almost no relation to Windows ANSI Western.
>>
>> I believe some of them are ANSI and ISO standards, but maybe not.
>>
>>> but they were never approved.
>>
>> Please provide evidence that they were submitted for standardization.
>
> Quoting https://en.wikipedia.org/wiki/Windows_code_page#ANSI_code_page :
>
>     ANSI Windows code pages, and especially the code page 1252,
>     were called that way since they were purportedly based on drafts
>     submitted or intended for ANSI. However, ANSI and ISO have not
>     standardized any of these code pages.

I think “any of these code pages” is an unwarranted and incorrect 
generalization in that quote.

But even if the Wikipedia text here were correct, which it doesn't seem 
to be, it would not then back up your claim that the code pages were 
“never approved” for standardization. For in order for approval to be a 
possibility they'd have to be submittedm. The quote does not say they've 
been submitted.


> My statement seems to have been imprecise.
>
>>>  The collection of code pages sometimes referred to as
>>> "Windows ANSI" have nothing to do with the American National Standards
>>> Institute.
>>
>> In that, you're right.
>>
>> But I have not written or implied the opposite.
>>
>> I think you're just trying to associate with me with the silly notions
>> that you APPEAR to be arguing against.
>>
>> If so then that's not very honest argumentation.
>
> I think you're overreacting to my criticism.  You referred to "Windows
> ANSI".  There's really no such thing, though it's a common misuse.

It's not a common misuse: it's the name of this concept. Again, you can 
read all about it in Microsoft's documentation (which I linked to) and 
in Wikipedia (which I linked to). It's misnomer, and it is the name. 
Lots of names are misnomers. This name is one, and still, just like 
other misnomer names, it's the name; what you use to refer to the thing.


Cheers!,

- Alf

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

#93243

On Monday, September 5, 2016 at 11:44:23 PM UTC+1, Keith Thompson wrote:
>
> That's not quite the same.  Microsoft's attempt to deprecate the
> standard string functions is absurd, since they're still in the ISO C
> standard.  Deprecating the name "ANSI" for certain Windows-specific
> character sets, on the other hand, is entirely reasonable.
> 
It's a thundering nuisance. As I said, I spent two weeks fiddling 
about with IDEs and directories, just to get Baby X to compile
on both Windows and Linux for the same git repository.

Turning off C string deprecation is one of the fiddles. It's just
a case of defining something to the pre-processor. But you've got
to do it again for release mode. And these fiddles are cumulative,
after two or three you can no longer remember them, so you've got 
to write a checklist of the user. 

It's easy enough to provide mystrcpy(), which buys you nothing in
terms of security. But mysprintf() is a bit more of a challenge,
and fopen() you can't reasonably do without. 

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web