"Unicode"

[Lynn McGuire]

"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

[Daniel]

Has he though? On this one?

I think the Unicode people have vastly simplified many people's lives.

Admittedly, C++ has badly screwed this up.

Daniel

[Lynn McGuire]

Microsoft has a big hand in the screw up with their decision to go with wide characters. But the Unicode consortium is getting wacky
here lately with adding emoticons to Unicode.
http://blog.unicode.org/2016/06/unicode-90-emoji-available-for-adoption.html

Lynn

[Richard]

[Please do not mail me a copy of your followup]

>On 8/29/2016 1:52 PM, Daniel wrote:
>> Admittedly, C++ has badly screwed this up.

I think you have your history backwards. C and C++ predate unicode.

The general consensus seems to be that you should use std::string with
UTF-8 encoding to add basic unicode support. You can always get
fancier if you need it with Qt, wxWidgets, UCS, etc.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Lynn McGuire]

On 8/30/2016 1:50 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
>> On 8/29/2016 1:52 PM, Daniel wrote:
>>> Admittedly, C++ has badly screwed this up.
>
> I think you have your history backwards. C and C++ predate unicode.
>
> The general consensus seems to be that you should use std::string with
> UTF-8 encoding to add basic unicode support. You can always get
> fancier if you need it with Qt, wxWidgets, UCS, etc.

You are replying to the wrong person.

Lynn

[Bo Persson]

On 2016-08-30 19:24, Lynn McGuire wrote:
> On 8/29/2016 1:52 PM, Daniel wrote:
>> On Monday, August 29, 2016 at 1:06:54 PM UTC-4, 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.
>>>
>> Has he though? On this one?
>>
>> I think the Unicode people have vastly simplified many people's lives.
>>
>> Admittedly, C++ has badly screwed this up.
>>
>> Daniel
>
> Microsoft has a big hand in the screw up with their decision to go with
> wide characters.

The decision was pretty obvious at the time, when their wchar_t could
hold all of the existing code space. Who would know that even-wider
characters would appear later?

> But the Unicode consortium is getting wacky here
> lately with adding emoticons to Unicode.
>
> http://blog.unicode.org/2016/06/unicode-90-emoji-available-for-adoption.html
>

Yes, adding a Bacon character doesn't look totally PK today. And the
meaning if crossing-fingers is not locale neutral.


Bo Persson

[Bo Persson]

Sorry, lost in translation. PK = politically correct.


> Bo Persson
>
>
>

[Richard]

[Please do not mail me a copy of your followup]

Lynn McGuire <lynnmc...@gmail.com> spake the secret code
<nq4lph$dff$1...@dont-email.me> thusly:

No, the attribution is correct, unless you're claiming to also be
posting under Daniel.[*] He's in my KILL file (probably for failure
to exercise self-control and flame on and on and on about religion)
so I don't see his messages unless someone else quotes him.

[*] the References header mentions your post because you quoted him.

[Vir Campestris]

On 30/08/2016 19:50, Richard wrote:
> The general consensus seems to be that you should use std::string with
> UTF-8 encoding to add basic unicode support. You can always get
> fancier if you need it with Qt, wxWidgets, UCS, etc.

It's the general consensus in the Linux world.

At the time that the C++ standard decided that it was not necessary to
handle file names with anything other than narrow chars Windows had most
of the desktop. And had file names that were not narrow chars. So the
C++ standard didn't support most of the desktops out there.

Andy

[Daniel]

On Tuesday, August 30, 2016 at 3:30:47 PM UTC-4, Bo Persson wrote:
> On 2016-08-30 19:24, Lynn McGuire wrote:
> >
> > Microsoft has a big hand in the screw up with their decision to go with
> > wide characters.
>
> The decision was pretty obvious at the time, when their wchar_t could
> hold all of the existing code space. Who would know that even-wider
> characters would appear later?
>

Computer languages should have string types that have string semantics. C++ doesn't, std::string is just an array of bytes, std::wstring is just an array of, well, pick your operating system. Neither of these instantiations of basic_string offers much of anything over any other sequence type in the language. Users have to be intimately aware of the character encoding, they shouldn't have to be.

Daniel

[Richard]

[Please do not mail me a copy of your followup]

Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
<KMidnZveE6s6cVjK...@brightview.co.uk> thusly:

>At the time that the C++ standard decided that it was not necessary to

>handle file names with anything other than narrow chars [...]

C++ had been around for 15+ years before it was standardized. The
standardization process was capturing existing practice more than it
was introducing fundamental changes to the language.

[Alf P. Steinbach]

On 31.08.2016 22:31, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
> <KMidnZveE6s6cVjK...@brightview.co.uk> thusly:
>
>> At the time that the C++ standard decided that it was not necessary to
>> handle file names with anything other than narrow chars [...]
>
> C++ had been around for 15+ years before it was standardized. The
> standardization process was capturing existing practice more

Uhm, that's bollocks.

One would have to search long and hard and wide to find a
standardization with more pure innovation than C++98.

Namespaces, exceptions, most of the standard library. Even compared to
the ARM it was extreme. Compiler vendors had a hard time catching up,
authors detailed their choices of practically necessary compatibility
trade-offs so as to not confer wrong impressions to their readers.

> than it was introducing fundamental changes to the language.

Uhm, ditto. Sorry.


Cheers & hth.,

- ALf

[Daniel]

On Wednesday, August 31, 2016 at 7:50:59 PM UTC-4, Alf P. Steinbach wrote:
>
> One would have to search long and hard and wide to find a
> standardization with more pure innovation than C++98.
>
> Namespaces, exceptions, most of the standard library

and export :-)

Best regards,
Daniel

[Jerry Stuckle]

On 8/31/2016 7:50 PM, Alf P. Steinbach wrote:
> On 31.08.2016 22:31, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
>> <KMidnZveE6s6cVjK...@brightview.co.uk> thusly:
>>
>>> At the time that the C++ standard decided that it was not necessary to
>>> handle file names with anything other than narrow chars [...]
>>
>> C++ had been around for 15+ years before it was standardized. The
>> standardization process was capturing existing practice more
>
> Uhm, that's bollocks.
>
> One would have to search long and hard and wide to find a
> standardization with more pure innovation than C++98.
>

Sorry, Richard is correct. C++98 was NOT the first standard.

> Namespaces, exceptions, most of the standard library. Even compared to
> the ARM it was extreme. Compiler vendors had a hard time catching up,
> authors detailed their choices of practically necessary compatibility
> trade-offs so as to not confer wrong impressions to their readers.
>

None of these were included in the initial C++ standard.

>
>> than it was introducing fundamental changes to the language.
>
> Uhm, ditto. Sorry.
>
>
> Cheers & hth.,
>
> - ALf
>

Later standards added these feature.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[Ian Collins]

On 09/ 1/16 03:06 PM, Jerry Stuckle wrote:
> On 8/31/2016 7:50 PM, Alf P. Steinbach wrote:
>> On 31.08.2016 22:31, Richard wrote:
>>> [Please do not mail me a copy of your followup]
>>>
>>> Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
>>> <KMidnZveE6s6cVjK...@brightview.co.uk> thusly:
>>>
>>>> At the time that the C++ standard decided that it was not necessary to
>>>> handle file names with anything other than narrow chars [...]
>>>
>>> C++ had been around for 15+ years before it was standardized. The
>>> standardization process was capturing existing practice more
>>
>> Uhm, that's bollocks.
>>
>> One would have to search long and hard and wide to find a
>> standardization with more pure innovation than C++98.
>>
>
> Sorry, Richard is correct. C++98 was NOT the first standard.

So what was?

--
Ian

[Alf P. Steinbach]

On 01.09.2016 05:06, Jerry Stuckle wrote:
> On 8/31/2016 7:50 PM, Alf P. Steinbach wrote:
>> On 31.08.2016 22:31, Richard wrote:
>>> [Please do not mail me a copy of your followup]
>>>
>>> Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
>>> <KMidnZveE6s6cVjK...@brightview.co.uk> thusly:
>>>
>>>> At the time that the C++ standard decided that it was not necessary to
>>>> handle file names with anything other than narrow chars [...]
>>>
>>> C++ had been around for 15+ years before it was standardized. The
>>> standardization process was capturing existing practice more
>>
>> Uhm, that's bollocks.
>>
>> One would have to search long and hard and wide to find a
>> standardization with more pure innovation than C++98.
>>
>
> Sorry, Richard is correct. C++98 was NOT the first standard.

I think Richard's error was just one of perception.

He shouldn't have posted those claims without checking, or including
qualifier phrases such as "I believe".

You, on the other hand, are just blatantly counter-factual. Why do you
persist in that? Why not try to be a bit constructive and maybe learn
something?


Baffled,

- Alf

[David Brown]

On 01/09/16 05:06, Jerry Stuckle wrote:
> On 8/31/2016 7:50 PM, Alf P. Steinbach wrote:
>> On 31.08.2016 22:31, Richard wrote:
>>> [Please do not mail me a copy of your followup]
>>>
>>> Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
>>> <KMidnZveE6s6cVjK...@brightview.co.uk> thusly:
>>>
>>>> At the time that the C++ standard decided that it was not necessary to
>>>> handle file names with anything other than narrow chars [...]
>>>
>>> C++ had been around for 15+ years before it was standardized. The
>>> standardization process was capturing existing practice more
>>
>> Uhm, that's bollocks.
>>
>> One would have to search long and hard and wide to find a
>> standardization with more pure innovation than C++98.
>>
>
> Sorry, Richard is correct. C++98 was NOT the first standard.

C++98 was the first /ISO/ standard of C++.

The first edition of "The C++ Programming Language" (1985) was the
defining reference for the language, but it was not an official
standard. The same applies to the ARM (1990).

C++ itself was from 1983 (after 4 years as "C with classes").

So Richard is correct on the timings, C++ had been around for 15 years
before it was standardised (C++98).

I can't comment on how much C++98 standardised existing practice or
invented new features - I don't know the tools of that era well enough.
Alf and Richard can fight that one if they want.

It is quite possible that the ARM was based on existing practice, and
certainly likely that "The C++ Programming Language" was based on
existing practice. But those were not standards, and they were not
written 15 or so years after C++ was first developed.

>
>> Namespaces, exceptions, most of the standard library. Even compared to
>> the ARM it was extreme. Compiler vendors had a hard time catching up,
>> authors detailed their choices of practically necessary compatibility
>> trade-offs so as to not confer wrong impressions to their readers.
>>
>
> None of these were included in the initial C++ standard.

The initial C++ standard was C++98, and included those features.

[Osmium]

"Daniel" <daniel...@gmail.com> wrote in message
news:4a13de5a-a74e-4edc...@googlegroups.com...

LOL

[Mr Flibble]

On 01/09/2016 04:06, Jerry Stuckle wrote:
> On 8/31/2016 7:50 PM, Alf P. Steinbach wrote:
>> On 31.08.2016 22:31, Richard wrote:
>>> [Please do not mail me a copy of your followup]
>>>
>>> Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
>>> <KMidnZveE6s6cVjK...@brightview.co.uk> thusly:
>>>
>>>> At the time that the C++ standard decided that it was not necessary to
>>>> handle file names with anything other than narrow chars [...]
>>>
>>> C++ had been around for 15+ years before it was standardized. The
>>> standardization process was capturing existing practice more
>>
>> Uhm, that's bollocks.
>>
>> One would have to search long and hard and wide to find a
>> standardization with more pure innovation than C++98.
>>
>
> Sorry, Richard is correct. C++98 was NOT the first standard.
>

C++98 was the first C++ standard.

I see the scope of your fractal wrongness is very wide indeed; I wonder
if there is a topic that your are NOT fractally wrong about?

/Flibble

[Richard]

[Please do not mail me a copy of your followup]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
<nq7qgl$9ts$1...@dont-email.me> thusly:

Alf, I respect your viewpoint, so I'll stand corrected on that. It
was my impression that standardization was more about codifying
existing practice at the time. Do you happen to have any links to
discussions/papers by Stroustrup at the time of the 98
standardization effort?

[Richard]

[Please do not mail me a copy of your followup]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code

<nq8ga7$r8a$1...@dont-email.me> thusly:

>I think Richard's error was just one of perception.
>
>He shouldn't have posted those claims without checking, or including
>qualifier phrases such as "I believe".

Yep, it was just my understanding (who else would I be posting for?)
and my understanding was wrong. Now I'm interested in reading more
about this period in the history of C++.

[Jerry Stuckle]

C++98 was the first ANSI/ISO standard. However, Stroustrups's book "The
C++ Programming Language" 1st and 2nd editions were recognized as the
standard before that time. The 3rd edition was considered a standard by
some, but ANSI was already working on a consensus standard by the time
the book came out.

But if you understood ANYTHING about the history of C++, you would know
that.

[Jerry Stuckle]

And once again you show your head is so far up your arse that you can
see your tonsils.

ANSI/IOC are NOT the only recognized standards in the world!

[Jerry Stuckle]

The 3rd edition of Stroustrup's book came out in 1997, and had a lot of
influence on the C++ standard being developed at the time - and vice
versa. It's probably the most reliable reference. I don't know of
other discussions/papers by him from that time off-hand.

[Mr Flibble]

Isn't it blindingly obvious that when someone uses the term "C++
standard" they are referring to a C++ ISO standard? Your fractal
wrongness does indeed run deep, fractally deep.

/Flibble

[David Brown]

Bjarne Stroustrup has quite a lot of information, faqs, links, and
papers on his webpage:

<http://www.stroustrup.com/C++.html>

There is a section on "design and history", which is as definitive a
reference as any.

(And note to Jerry - Stroustrup talks about the ARM as a step towards
standardisation and a basis for a standard, but considers the ANSI/ISO
standards to be the point at which the language actually has a proper
standard.)

[Mr Flibble]

On 01/09/2016 21:27, David Brown wrote:
>
> (And note to Jerry - Stroustrup talks about the ARM as a step towards
> standardisation and a basis for a standard, but considers the ANSI/ISO
> standards to be the point at which the language actually has a proper
> standard.)

No doubt Mr Stuckle will now tell us the difference between "a standard"
and "the standard" and of course he will be fractally wrong in what he
says yet again.

/Flibble

[Mr Flibble]

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

[Jerry Stuckle]

Nope. ISO is not the only standard in the world - and was not the only
recognized C++ standard.

But once again you're just showing you're no more than a stoopid troll.
Nothing new here.

[Jerry Stuckle]

Maybe HE did. But the rest of the world considered his books to be the
standard. This included AT&T, Microsoft, IBM, Borland... and many others.

[Alf P. Steinbach]

On 01.09.2016 20:45, Richard wrote:
> [Please do not mail me a copy of your followup]
>

> "Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
> <nq7qgl$9ts$1...@dont-email.me> thusly:

>> [snip]

>> One would have to search long and hard and wide to find a
>> standardization with more pure innovation than C++98.
>>
>> Namespaces, exceptions, most of the standard library. Even compared to
>> the ARM it was extreme. Compiler vendors had a hard time catching up,
>> authors detailed their choices of practically necessary compatibility
>> trade-offs so as to not confer wrong impressions to their readers.
>>> than it was introducing fundamental changes to the language.
>>
>> Uhm, ditto. Sorry.
>
> Alf, I respect your viewpoint, so I'll stand corrected on that. It
> was my impression that standardization was more about codifying
> existing practice at the time. Do you happen to have any links to
> discussions/papers by Stroustrup at the time of the 98
> standardization effort?
>

Not sure why you want to limit the authors to Bjarne Stroustrup. E.g.
Bjarne and Alexander Stepanov cooperated on bring the STL into the
standard library, and I don't think Bjarne wrote an article about that.

Anyway, from ¹Stroustrup's own web pages:

• B. Stroustrup: The C++ Programming Language (3rd Edition).
Addison-Wesley Longman. Reading Mass. USA. 1997. ISBN 0-201-88954-4.

• B. Stroustrup: A perspective on Concurrency and C++. in Wilson & Lu
(Editors): Parallel Programming using C++. The MIT Press. 1996. ISBN
0-262-73118-5.

• B. Stroustrup: Language-technical Aspects of Reuse. Proc. 4th
International Conference on Software reuse, pp 11-19. April 1996.
B. Stroustrup: A Brief Look at C++. IEEE AI Expert, Intelligent Systems
and their Applications, pp 13-15. February 1996.

• A. R. Koenig and B. Stroustrup: Foundations for Native C++ Styles.
Software Practice and Experience. Vol 25, special issue S4. December 1995.

• B. Stroustrup: A Perspective on ISO C++. The C++ Report. Vol 7/No 8,
pp 22-28. October 1995. Also in "C++ Gems" (editor: Stan Lippman) SIGS
Publications, 1996. ISBN 1-884842-37-2.

• B. Stroustrup: Why C++ isn't just an Object-Oriented Programming
Language. Addendum to OOPSLA'95 Proceedings. OOPS Messenger, vol 6 no 4,
pp 1-13. October 1995.

• B. Stroustrup: Making a vector fit for a Standard. The C++ Report.
October 1994. Also in "C++ Gems" (editor: Stan Lippman) SIGS
Publications, 1996. ISBN 1-884842-37-2.

• B. Stroustrup: The Design and Evolution of C++. Addison Wesley, ISBN
0-201-54330-3. March 1994.

• B. Stroustrup, A. Koenig, and B. Moo: The C++ Programming Language.
Encyclopedia of Software Engineering. Wiley. ISBN 0-471-54004-8.
February 1994.

• B. Stroustrup: The Simula Programming Language. Encyclopedia of
Software Engineering. Wiley. ISBN 0-471-54004-8. February 1994.

• B. Stroustrup: On Learning C++. Martin Heller: Advanced Win32
Programming. Wiley. July 1993.

• B. Stroustrup: Why Consider Language Extensions?. Proc. European C++
Users' Group Meeting, Munich. July 1993. Also, The C++ Report. Vol 5 no 7.

• B. Stroustrup: Library Design Using C++. The C++ Report. Vol 5 no 5,
pp 14-22. June 1993. Also in "C++ Gems" (editor: Stan Lippman) SIGS
Publications, 1996. ISBN 1-884842-37-2.

• B. Stroustrup: A History of C++: 1979-1991. Proc ACM History of
Programming Languages conference (HOPL-2). ACM Sigplan Notices. Vol 28
No 3, pp 271-298. March 1993. Also, History of Programming languages
(editors T.J.Begin and R.G.Gibson) Addison-Wesley, ISBN 1-201-89502-1. 1996.

• B. Stroustrup: We're not in Kansas Anymore. The C++ Report ``Moving
from C to C++'' supplement. SIGS Publications. August 1992.

• B. Stroustrup: Tracing the roots of C++. Silver Anniversary
Supplement. SIGS Publications. August 1992.

• B. Stroustrup D. Lenkov: Run-Time Type Identification for C++
(Revised). Proc USENIX C++ Conference. August 1992.

• B. Stroustrup, et.al.: How to Write a C++ Language Extension Proposal.
The C++ Report, pp 40-47. May 1992 Also, ACM Sigplan Notices, Vol 27 No
6 June 1992 pp 64-71.

• B. Stavtrup: Overloading of C++ Whitespace. Journal of Object-Oriented
Programming. April 1, 1992.

• B. Stroustrup: C++ 3.0, Standardisering, og andet godt. PC World
(Danmark). March 1992 (in Danish).

• B. Stroustrup and D. Lenkov: Run-Time Type Identification for C++. The
C++ Report, Vol 4 No 3, pp 32-42. March/April 1992.

• B. Stroustrup: The C++ Programming Language (2nd Edition). Addison
Wesley, ISBN 0-201-53992-6. June 1991.

• B. Stroustrup: What is Object-Oriented Programming? (1991 revised
version). Proc. 1st European Software Festival. February, 1991.

• B. Stroustrup: Sixteen Ways to Stack a Cat. The C++ Report. Oct 1990.
(a somewhat odd paper provided by popular demand).

• M. A. Ellis and B. Stroustrup: The Annotated C++ Reference Manual.
Addison Wesley, ISBN 0-201-51459-1. May 1990.

In the period from 1990 to 1998 the ARM, in the last bullet point above,
constituted a /de facto/ standard, but it became increasingly incorrect
in both details and some main aspects as the standardization process
changed the language. E.g., the rule for destruction of temporaries was
clarified and slightly changed in C++98, a detail. And e.g. namespaces,
a main aspect, were introduced after the ARM.


Cheers & hth.,

- Alf

Notes:
¹ <url: http://www.stroustrup.com/papers.html>

[Mr Flibble]

Fractal wrongness: the state of being wrong at every conceivable scale
of resolution. That is, from a distance, a fractally wrong person's
worldview is incorrect; and furthermore, if you zoom in on any small
part of that person's worldview, that part is just as wrong as the whole
worldview.

http://rationalwiki.org/wiki/Fractal_wrongness

>
> But once again you're just showing you're no more than a stoopid troll.
> Nothing new here.

Project much mate?

/Flibble

[Jerry Stuckle]

ROFLMAO! You are completely clueless, as usual. But that's not
surprising for a stoopid troll (which you yourself have shown to be).

>>
>> But once again you're just showing you're no more than a stoopid troll.
>> Nothing new here.
>
> Project much mate?
>
> /Flibble
>
>

Yes, you do project a lot. But that's what trolls do. And you've
proven yourself to be one. Not a very good one, but a funny one at times.

You don't even know C++ now - and never were programming in C++ before
the C98 standard came out. How would you know?

And according to you, Java has no standard because there is not an IOS
standard. However, Oracle and millions of programmers around the world
would disagree with you.

But you'd claim to be right on that, also. What's next - the sun rising
in the west? Or does that happen only in the Southern Hemisphere?

It's no wonder you've never been able to get a decent job.

[Mr Flibble]

On 02/09/2016 15:10, Jerry Stuckle wrote:
[snip]

> Yes, you do project a lot. But that's what trolls do. And you've
> proven yourself to be one. Not a very good one, but a funny one at times.
>
> You don't even know C++ now - and never were programming in C++ before
> the C98 standard came out. How would you know?
>
> And according to you, Java has no standard because there is not an IOS
> standard. However, Oracle and millions of programmers around the world
> would disagree with you.
>
> But you'd claim to be right on that, also. What's next - the sun rising
> in the west? Or does that happen only in the Southern Hemisphere?
>
> It's no wonder you've never been able to get a decent job.
>

Fractal wrongness: the state of being wrong at every conceivable scale
of resolution. That is, from a distance, a fractally wrong person's
worldview is incorrect; and furthermore, if you zoom in on any small
part of that person's worldview, that part is just as wrong as the whole
worldview.

http://rationalwiki.org/wiki/Fractal_wrongness

/Flibble

[Mr Flibble]

On 02/09/2016 15:10, Jerry Stuckle wrote:
[snip]

> Yes, you do project a lot. But that's what trolls do. And you've
> proven yourself to be one. Not a very good one, but a funny one at times.

You even project projection; you are in serious need of medication.

>
> You don't even know C++ now - and never were programming in C++ before
> the C98 standard came out. How would you know?

I don't know C++? Funny but https://github.com/FlibbleMr/ is entirely my
own work and I use C++ every day at work as a senior software engineer.
These are surely amazing feats for someone who doesn't know C++.

I have been coding in C++ since 1993 (five years before the FIRST C++
ISO standard).

>
> And according to you, Java has no standard because there is not an IOS
> standard. However, Oracle and millions of programmers around the world
> would disagree with you.

Java is off topic however I'll bite: what you are talking about are
called "de facto standards" not "standards".

>
> But you'd claim to be right on that, also. What's next - the sun rising
> in the west? Or does that happen only in the Southern Hemisphere?

Strawman.

>
> It's no wonder you've never been able to get a decent job.

Whether or not any of my jobs were/are "decent" is highly subjective. I
was a member of the tiger team for and I wrote a fair bit of the
software for the world's first smartphone (the Ericsson R380); is that
"decent" enough for you?

/Flibble

[Jerry Stuckle]

You keep saying that. But that doesn't make it true.

Your inability to get a decent job, however, is true. So are your
demonstrated lack of C++ knowledge and that you are a troll.

You keep trying. But it doesn't work.

[Jerry Stuckle]

On 9/2/2016 12:02 PM, Mr Flibble wrote:
> On 02/09/2016 15:10, Jerry Stuckle wrote:
> [snip]
>> Yes, you do project a lot. But that's what trolls do. And you've
>> proven yourself to be one. Not a very good one, but a funny one at
>> times.
>
> You even project projection; you are in serious need of medication.
>

Nope. You have proven youself time and time again to be a trill.

>>
>> You don't even know C++ now - and never were programming in C++ before
>> the C98 standard came out. How would you know?
>
> I don't know C++? Funny but https://github.com/FlibbleMr/ is entirely my
> own work and I use C++ every day at work as a senior software engineer.
> These are surely amazing feats for someone who doesn't know C++.
>
> I have been coding in C++ since 1993 (five years before the FIRST C++
> ISO standard).
>

ROFLMAO! So you've been coding C++ since 1993. Maybe one of these days
you'll get it right. I doubt it, though. You've already proven
yourself to be hopeless.

And BTW - I've been programing C++ since 1988 - one year after the first
commercial compiler from AT&T was released in (in beta form).

>>
>> And according to you, Java has no standard because there is not an IOS
>> standard. However, Oracle and millions of programmers around the world
>> would disagree with you.
>
> Java is off topic however I'll bite: what you are talking about are
> called "de facto standards" not "standards".
>

Nope, they are standards. The fact the standards aren't issued by ISO
does not mean they are not standards.

>>
>> But you'd claim to be right on that, also. What's next - the sun rising
>> in the west? Or does that happen only in the Southern Hemisphere?
>
> Strawman.
>

No, a serious question for you. Maybe you can google it.

>>
>> It's no wonder you've never been able to get a decent job.
>
> Whether or not any of my jobs were/are "decent" is highly subjective. I
> was a member of the tiger team for and I wrote a fair bit of the
> software for the world's first smartphone (the Ericsson R380); is that
> "decent" enough for you?
>
> /Flibble

So you claim. You wouldn't last two weeks on any competent team.

But then how many smartphones is Ericsson making now? That was a huge
success, wasn't it?

[Mr Flibble]

On 02/09/2016 17:33, Jerry Stuckle wrote:
> On 9/2/2016 12:02 PM, Mr Flibble wrote:
>> On 02/09/2016 15:10, Jerry Stuckle wrote:
>> [snip]
>>> Yes, you do project a lot. But that's what trolls do. And you've
>>> proven yourself to be one. Not a very good one, but a funny one at
>>> times.
>>
>> You even project projection; you are in serious need of medication.
>>
>
> Nope. You have proven youself time and time again to be a trill.

Youself? Trill? Are you having a stroke now? Can't get your troll out
quick enough eh mate?

>
>>>
>>> You don't even know C++ now - and never were programming in C++ before
>>> the C98 standard came out. How would you know?
>>
>> I don't know C++? Funny but https://github.com/FlibbleMr/ is entirely my
>> own work and I use C++ every day at work as a senior software engineer.
>> These are surely amazing feats for someone who doesn't know C++.
>>
>> I have been coding in C++ since 1993 (five years before the FIRST C++
>> ISO standard).
>>
>
> ROFLMAO! So you've been coding C++ since 1993. Maybe one of these days
> you'll get it right. I doubt it, though. You've already proven
> yourself to be hopeless.

I repeat: https://github.com/FlibbleMr/ is entirely my own work and I

use C++ every day at work as a senior software engineer. These are

surely amazing feats for someone "who doesn't know C++" and/or "is
hopeless" and can't "get it right".

>
> And BTW - I've been programing C++ since 1988 - one year after the first
> commercial compiler from AT&T was released in (in beta form).

I am amazed that someone with your claimed experience can seemingly do
nothing but troll others on Usenet.

>
>>>
>>> And according to you, Java has no standard because there is not an IOS
>>> standard. However, Oracle and millions of programmers around the world
>>> would disagree with you.
>>
>> Java is off topic however I'll bite: what you are talking about are
>> called "de facto standards" not "standards".
>>
>
> Nope, they are standards. The fact the standards aren't issued by ISO
> does not mean they are not standards.

Yep, a de facto standard is not the same thing as a standard.

>
>>>
>>> But you'd claim to be right on that, also. What's next - the sun rising
>>> in the west? Or does that happen only in the Southern Hemisphere?
>>
>> Strawman.
>>
>
> No, a serious question for you. Maybe you can google it.

No, it is a strawman.

>
>>>
>>> It's no wonder you've never been able to get a decent job.
>>
>> Whether or not any of my jobs were/are "decent" is highly subjective. I
>> was a member of the tiger team for and I wrote a fair bit of the
>> software for the world's first smartphone (the Ericsson R380); is that
>> "decent" enough for you?
>>
>> /Flibble
>
>
> So you claim. You wouldn't last two weeks on any competent team.

You keep making these groundless assertions based on no evidence all the
time, why do you do it? You know it just makes you look like an idiot
right?

All the teams I have worked with were competent and I was a member of
them for years and left them on my own terms.

>
> But then how many smartphones is Ericsson making now? That was a huge
> success, wasn't it?

Yes it was a success actually. I left Sony Ericsson in 2003 and they
continued to be successful for several years after that. Sony Ericsson's
mistake was sticking with Symbian OS rather than embracing Android when
it was clear that that was where the smart money was going. Nevertheless
Sony Ericsson was folded back into Sony Mobile and they continue to do
quite well now. Sony Android phones are great.

/Flibble

[Gareth Owen]

Mr Flibble <flibbleREM...@i42.co.uk> writes:

>>
>> And BTW - I've been programing C++ since 1988 - one year after the first
>> commercial compiler from AT&T was released in (in beta form).
>
> I am amazed that someone with your claimed experience can seemingly do
> nothing but troll others on Usenet.

That's a bit harsh. Those consulting companies didn't bankrupt
themselves, you know

[Jerry Stuckle]

On 9/2/2016 12:53 PM, Mr Flibble wrote:
> On 02/09/2016 17:33, Jerry Stuckle wrote:
>> On 9/2/2016 12:02 PM, Mr Flibble wrote:
>>> On 02/09/2016 15:10, Jerry Stuckle wrote:
>>> [snip]
>>>> Yes, you do project a lot. But that's what trolls do. And you've
>>>> proven yourself to be one. Not a very good one, but a funny one at
>>>> times.
>>>
>>> You even project projection; you are in serious need of medication.
>>>
>>
>> Nope. You have proven youself time and time again to be a trill.
>
> Youself? Trill? Are you having a stroke now? Can't get your troll out
> quick enough eh mate?
>

ROFLMAO! Another stoopid comment by a stoopid troll.

But in your case, "trill" might be a better description!

>>
>>>>
>>>> You don't even know C++ now - and never were programming in C++ before
>>>> the C98 standard came out. How would you know?
>>>
>>> I don't know C++? Funny but https://github.com/FlibbleMr/ is entirely my
>>> own work and I use C++ every day at work as a senior software engineer.
>>> These are surely amazing feats for someone who doesn't know C++.
>>>
>>> I have been coding in C++ since 1993 (five years before the FIRST C++
>>> ISO standard).
>>>
>>
>> ROFLMAO! So you've been coding C++ since 1993. Maybe one of these days
>> you'll get it right. I doubt it, though. You've already proven
>> yourself to be hopeless.
>
> I repeat: https://github.com/FlibbleMr/ is entirely my own work and I
> use C++ every day at work as a senior software engineer. These are
> surely amazing feats for someone "who doesn't know C++" and/or "is
> hopeless" and can't "get it right".
>

Yup, and pretty crappy work, at that. I'd be embarrassed to claim work
like that.

>>
>> And BTW - I've been programing C++ since 1988 - one year after the first
>> commercial compiler from AT&T was released in (in beta form).
>
> I am amazed that someone with your claimed experience can seemingly do
> nothing but troll others on Usenet.
>

This from a proven troll!

>>
>>>>
>>>> And according to you, Java has no standard because there is not an IOS
>>>> standard. However, Oracle and millions of programmers around the world
>>>> would disagree with you.
>>>
>>> Java is off topic however I'll bite: what you are talking about are
>>> called "de facto standards" not "standards".
>>>
>>
>> Nope, they are standards. The fact the standards aren't issued by ISO
>> does not mean they are not standards.
>
> Yep, a de facto standard is not the same thing as a standard.
>

A standard is a standard. Period.

>>
>>>>
>>>> But you'd claim to be right on that, also. What's next - the sun
>>>> rising
>>>> in the west? Or does that happen only in the Southern Hemisphere?
>>>
>>> Strawman.
>>>
>>
>> No, a serious question for you. Maybe you can google it.
>
> No, it is a strawman.
>

Nope. A serious question - but obviously one you can't answer!

But then you don't know what a strawman is either, do you?

>>
>>>>
>>>> It's no wonder you've never been able to get a decent job.
>>>
>>> Whether or not any of my jobs were/are "decent" is highly subjective. I
>>> was a member of the tiger team for and I wrote a fair bit of the
>>> software for the world's first smartphone (the Ericsson R380); is that
>>> "decent" enough for you?
>>>
>>> /Flibble
>>
>>
>> So you claim. You wouldn't last two weeks on any competent team.
>
> You keep making these groundless assertions based on no evidence all the
> time, why do you do it? You know it just makes you look like an idiot
> right?
>
> All the teams I have worked with were competent and I was a member of
> them for years and left them on my own terms.
>

Your posts in this and other newsgroups speak otherwise. I don't know a
single team I've ever worked with who would hire you.

>>
>> But then how many smartphones is Ericsson making now? That was a huge
>> success, wasn't it?
>
> Yes it was a success actually. I left Sony Ericsson in 2003 and they
> continued to be successful for several years after that. Sony Ericsson's
> mistake was sticking with Symbian OS rather than embracing Android when
> it was clear that that was where the smart money was going. Nevertheless
> Sony Ericsson was folded back into Sony Mobile and they continue to do
> quite well now. Sony Android phones are great.
>
> /Flibble
>

You got your arse fired for incompetence, you mean. Which is why you've
never been able to get a decent job since then.

[Mr Flibble]

On 02/09/2016 21:36, Jerry Stuckle wrote:
[snip]

>
> You got your arse fired for incompetence, you mean. Which is why you've
> never been able to get a decent job since then.

I thought I never had a decent job mate? Backtracking are we? I was at
Ericsson/Sony Ericsson for over four years .. if I was "incompetent" I
wouldn't have lasted five minutes. BTW I have never been fired from a
job in my entire life and my current job is certainly "decent".

So how many of your consultancy companies when bankrupt again?

/Flibble

[Jerry Stuckle]

Nope, you didn't. The only one you could have possibly had you got
fired. And you just proved it.

Just like a troll.

And none of my consultancy companies have gone bankrupt. I probably
make more in a day than you do in a week.

[Richard Bos]

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

[Mr Flibble]

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

[Alf P. Steinbach]

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.

[Paavo Helde]

On 4.09.2016 10:56, Alf P. Steinbach wrote:
> On 03.09.2016 21:10, Mr Flibble wrote:
>> Richard Bos <ral...@xs4all.nl> wrote:
>>> Mr Flibble <flibbleREM...@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

[Vir Campestris]

On 04/09/2016 08: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.

I don't recall the API off the top of my head, but I do recall that you
can set your character set to UTF-8 in Windows.

Doubtless not in a portable manner... but then AIUI setting it to
anything else can't be done on Linux.

Andy

[Paavo Helde]

On 4.09.2016 23:37, Vir Campestris wrote:
> On 04/09/2016 08: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.
>
> I don't recall the API off the top of my head, but I do recall that you
> can set your character set to UTF-8 in Windows.

Sure you can set it ... but the machine won't boot up again after
restart. At least this was my experience when I last tried that.

To be honest, this was with Win7 several years ago. Maybe they have
fixed this meanwhile, if so, it would mean a major breakthrough towards
portable software. But somehow I doubt it.

> Doubtless not in a portable manner... but then AIUI setting it to
> anything else can't be done on Linux.

If this is so, then probably this is because setting it to anything else
has no point, so no software has been tested with it.

Cheers
Paavo

[Alf P. Steinbach]

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

[Paavo Helde]

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

[Alf P. Steinbach]

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>

[Paavo Helde]

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

[Vir Campestris]

On 04/09/2016 22:22, Paavo Helde wrote:
> On 4.09.2016 23:37, Vir Campestris wrote:
>>
>> I don't recall the API off the top of my head, but I do recall that you
>> can set your character set to UTF-8 in Windows.
>
> Sure you can set it ... but the machine won't boot up again after
> restart. At least this was my experience when I last tried that.

Never tried it at a system level, only within an app.

And of course, once you've done it, Alf's

>> std::ofstream f( utf8_file_path );

maps down to CreateFileA, with a glue layer converting the current UTF-8
code page into UTF-16 for the underlying CreateFileW call - and all is good.

Windows is shit, but it's not _that_ shit :)

Andy

[Paavo Helde]

This is interesting. So how do you set the UTF-8 locale for a Windows
process? The setlocale() function is documented to fail, see
https://msdn.microsoft.com/en-us/library/x99tb11d.aspx :

"The set of available locale names, languages, country/region codes, and
code pages includes all those supported by the Windows NLS API except
code pages that require more than two bytes per character, such as UTF-7
and UTF-8. If you provide a code page value of UTF-7 or UTF-8, setlocale
will fail, returning NULL."


(Yes, you can imbue a stream with some converter which converts the text
output from utf-8 to utf-16 (though why anybody would need that?), but
this is not what we are talking about here.)


Cheers
Paavo

[Alf P. Steinbach]

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.

[Keith Thompson]

"Alf P. Steinbach" <alf.p.stein...@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) ks...@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"

[Mr Flibble]

boost.filesystem

/Flibble

[Alf P. Steinbach]

On 06.09.2016 00:35, Keith Thompson wrote:
> "Alf P. Steinbach" <alf.p.stein...@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>

[Keith Thompson]

"Alf P. Steinbach" <alf.p.stein...@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.

[Alf P. Steinbach]

On 06.09.2016 01:17, Keith Thompson wrote:
> "Alf P. Steinbach" <alf.p.stein...@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

[Keith Thompson]

"Alf P. Steinbach" <alf.p.stein...@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]

[Alf P. Steinbach]

On 06.09.2016 02:16, Keith Thompson wrote:
> "Alf P. Steinbach" <alf.p.stein...@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

[Vir Campestris]

This is weird. You can call chcp 65001 on a command prompt to set it to
UTF-8, and I'm absolutely certain I've done it from an app in the past.
And yet I can't find the documentation for it anywhere. I wonder if it's
something that used to work, but doesn't any more?

It's either that or too much Linux has rotted my brain.

Andy

[Alf P. Steinbach]

On 07.09.2016 22:19, Vir Campestris wrote:
<>
> This is weird. You can call chcp 65001 on a command prompt to set it to
> UTF-8, and I'm absolutely certain I've done it from an app in the past.
> And yet I can't find the documentation for it anywhere. I wonder if it's
> something that used to work, but doesn't any more?

The Windows API level has never supported UTF-8 in consoles. The
behavior has been as if errors are sticky. Output could work till the
first non-ASCII character, but input wouldn't work at all (down at the
API level).

In Windows versions before Windows 8, using codepage 65000 would get you
funny “out of memory” and other errors, from e.g. "more" command:

[example]
[c:\my\forums\clc++]
> chcp 65000
Active code page: 65000

[c:\my\forums\clc++]
> more
Not enough memory.

[c:\my\forums\clc++]
> ver
Microsoft Windows [Version 6.1.7601]
[/example]

I'm not sure exactly when that was fixed, but as I recall it's not that
same idiotic error message in Windows 10; maybe no error.

Windows 10 got a lot of improvements in the console subsystem, including
ordinary shortkeys for copy/paste, unwrapping of wrapped output lines,
and once again support for ANSI escape sequences.

However, the escape sequence support isn't quite quite yet, and it
doesn't work with Windows Script Host, apparently because WSH uses
direct Unicode console i/o while (apparently) the escape sequences only
work for byte streams -- which is sort of ironic, that the now almost
deprecated WSH console i/o is not poor enough to get the benefits…


Cheers!,

- Alf