std::wstring considered useless

[Mr Flibble]

std::wstring is useless because "wide" characters are useless. You are
using it because Windows and/or Qt uses UTF-16? Well don't: UTF-8 is the
far superior choice and should be used in all of your code base except
at the OS/Framework API interface where you may have no choice but to
use "wide" characters sausages.

http://utf8everywhere.org/

/Flibble

[Paavo Helde]

I fully agree with this manifesto, and all my own code uses UTF-8
internally. But I think it would be still hard to convince Windows-only
programmers to use UTF-8 in their programs. Of course, they don't need
to use std::wstring either, CString would probably be fine for them.

Cheers
Paavo

[JiiPee]

I guess one question is also that which one is easier to use. seems like
wstring makes things easier....

[Mr Flibble]

Why do you think std::wstring makes things easier? It has absolutely no
advantages compared to UTF-8 apart from simplifying interfacing with a
pre-existing wide character API. In case you didn't know UTF-16 is also
a variable length encoding like UTF-8 so even that isn't a reason to use
it sausages.

/Flibble

[Richard]

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

Paavo Helde <myfir...@osa.pri.ee> spake the secret code
<Y5adnX6SX8O_PgvL...@giganews.com> thusly:

>> http://utf8everywhere.org/
>
>I fully agree with this manifesto, and all my own code uses UTF-8
>internally. But I think it would be still hard to convince Windows-only
>programmers to use UTF-8 in their programs. Of course, they don't need
>to use std::wstring either, CString would probably be fine for them.

Nit: don't confuse "Windows-only programmers" with "MFC Programmers".
--
"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>

[JiiPee]

On 13/01/2016 20:47, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Paavo Helde <myfir...@osa.pri.ee> spake the secret code
> <Y5adnX6SX8O_PgvL...@giganews.com> thusly:
>
>>> http://utf8everywhere.org/
>> I fully agree with this manifesto, and all my own code uses UTF-8
>> internally. But I think it would be still hard to convince Windows-only
>> programmers to use UTF-8 in their programs. Of course, they don't need
>> to use std::wstring either, CString would probably be fine for them.
> Nit: don't confuse "Windows-only programmers" with "MFC Programmers".

why would somebody do windows only programming :)?? going back to C
language??

[Christopher Pisz]

So, then we can translate from CString used internally to std::strings
used by every thrid party library? and be forced to include MFC in every
project to have the craptastic CString in the first place? Then we can
convert to BSTR for COM too while we're at it and back again, and leak
memory everywhere.

I use std::wstring for unicode and std::string for multibyte, because it
works with every single third part libray in itself or through a call to
c_str(). BSTR in COM is converted automitaclly for me from wachar_t *,
and I the only conversion I ever have to worry about is wide to
multibyte or the other way around.

I've worked on enough windows services that spent 95% of thier
processing converting strings to every silly type under the rainbow in
Windows.

Windows is going to convert everything to wide for you anyway on any API
call, so just pass it wchar_t * obtained from std::wstring in most cases.

[Paavo Helde]

On 13.01.2016 22:47, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Paavo Helde <myfir...@osa.pri.ee> spake the secret code
> <Y5adnX6SX8O_PgvL...@giganews.com> thusly:
>
>>> http://utf8everywhere.org/
>>
>> I fully agree with this manifesto, and all my own code uses UTF-8
>> internally. But I think it would be still hard to convince Windows-only
>> programmers to use UTF-8 in their programs. Of course, they don't need
>> to use std::wstring either, CString would probably be fine for them.
>
> Nit: don't confuse "Windows-only programmers" with "MFC Programmers".

I think there is some variant of CString (ATL CString?) which can be
used in Windows C++ programs even without MFC. Not that I would advocate
that.

[Jorgen Grahn]

To be able to use the APIs and features which are unique to Windows,
or which work differently on Windows -- because you want your programs
to run there, and you want them to run well.

Almost all my programming is Unix-specific for the same reason.

But a lot of people have wasted a lot of time and money over the
years, trying to get portability to platforms which they never
used.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Mr Flibble]

You can't use std::wstring for Unicode in general (not Windows) as
std::wstring HAS NOTHING TO DO WITH UNICODE: as far as C++ is concerned
there are no guarantees related to the wchar_t type and Unicode.

Even if wchar_t can be used to encode UTF-16 on your particular platform
see the manifesto as to why UTF-16 is the worst option. If you want to
use Unicode the only two sensible options are UTF-8 and UTF-32.

The goal should be to make as much of your code as portable as possible
(using an appropriate layered design) which means, if you want to use
Unicode, NOT using std::wstring as much as possible (even on Windows)
sausages.

/Flibble

[Christopher Pisz]

Why should that be the goal when 100% of customers use Windows and we
have 0 prospects asking for any other OS and 0 requests for using a
different OS in over 20 years of business? Why should I give two poops
about portability? Because its the cool thing to do?

[Christopher Pisz]

Furthermore, what you are talking about is fantasy. When you convince
Microsoft to take the following out of Windows.h, we'll talk about it:

// Generic types

#ifdef UNICODE
typedef wchar_t TCHAR;
#else
typedef unsigned char TCHAR;
#endif

typedef TCHAR *LPTSTR, *LPTCH;

// 8-bit character specific

typedef unsigned char CHAR;
typedef CHAR *LPSTR, *LPCH;

// Unicode specific (wide characters)

typedef unsigned wchar_t WCHAR;
typedef WCHAR *LPWSTR, *LPWCH;


One would assume, that if you are programming on Windows, you all
calling the Windows API, and if you have the Unicode flag set in your
project, guess what every single call to the Windows API is going to
expect and return? That's right, wchar_t *.

So, how in the world do you propose a Windows programmer is going to
call the Windows API while adhering to your nonsense about not using
wchar_t? Well, they can't. As you said yourself in your post "except in
calls to the OS". So, what happens then? We get to waste all of our
cycles transforming all of our string in every single call, to some
other string representation, not to mention the slew of extra code and
bugs you want to introduce, just so we can get your checky mark? No thanks.

A) wchar_t is in the language
B) It works with the Windows API
C) It works with COM when assigning to and from BSTR
C1) You are probably going to use COM, since you're programming
Windows, even though it is the devil.
D) It requires no transformation to any other type to use internally and
externally

[Richard]

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

Paavo Helde <myfir...@osa.pri.ee> spake the secret code

<j9OdnSCvMOO_RAvL...@giganews.com> thusly:

For a long time (changed with Community edition of VS 2015, I think),
ATL and MFC were not available with the free development tools, so as a
general rule people that are "Windows only" but concentrated on projects
that were open source or emphasized free development tools have stayed
away from MFC, ATL and CString.

People may be "Windows only programmers" and never touch MFC. (I hope to
not have to touch MFC code ever again.) Many "Windows only" programmers
use wxWidgets or Qt because they are comprehensive UI frameworks that are
freely available. In desktop GUI application developers that I talk to,
even "Windows only" developers, MFC has been losing mindshare steadily for
years and years. The only developers I encounter that use MFC routinely
are those that deal with legacy code bases that were written in MFC
in the first place. Everyone else I talk to is using Qt or wxWidgets.
YMMV, of course.

[Richard]

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

Christopher Pisz <nos...@notanaddress.com> spake the secret code
<n78gtt$ri2$1...@dont-email.me> thusly:

>Why should that be the goal when 100% of customers use Windows and we
>have 0 prospects asking for any other OS and 0 requests for using a
>different OS in over 20 years of business? Why should I give two poops
>about portability? Because its the cool thing to do?

It can be advantageous to have your business logic separated out from
the GUI and OS enough that you can at least compile your core IP with
another compiler that isn't MSVC. Each compiler has strengths and
weaknesses and having your code compiled by more than one compiler can
help you find subtle bugs in your code just by compiling it.

The same is true for people who only care about linux. It can be
advantageous to have your code compiled by MSVC and see what it points
out. Even better is to have your code compiled by all three major
compilers: gcc, clang and MSVC.

[Christopher Pisz]

On 1/14/2016 12:03 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Christopher Pisz <nos...@notanaddress.com> spake the secret code
> <n78gtt$ri2$1...@dont-email.me> thusly:
>
>> Why should that be the goal when 100% of customers use Windows and we
>> have 0 prospects asking for any other OS and 0 requests for using a
>> different OS in over 20 years of business? Why should I give two poops
>> about portability? Because its the cool thing to do?
>
> It can be advantageous to have your business logic separated out from
> the GUI and OS enough that you can at least compile your core IP with
> another compiler that isn't MSVC. Each compiler has strengths and
> weaknesses and having your code compiled by more than one compiler can
> help you find subtle bugs in your code just by compiling it.
>
> The same is true for people who only care about linux. It can be
> advantageous to have your code compiled by MSVC and see what it points
> out. Even better is to have your code compiled by all three major
> compilers: gcc, clang and MSVC.
>

What compiler can't handle wchar_t?

The OP is talking about portability at runtime with the OS environment
and the cult's mentality that uses it, by transforming all the calls to
Windows and back into a multibyte UTF8 string representation rather than
using wide characters when Windows is expecting wide characters as soon
as you make it a unicode project.

[Öö Tiib]

In practice the conversion between UTF-16 LE and UTF-8 is so trivial that
there will be typically insignificant difference in product performance
(about like pointless extra copy been made). Of course if there are no
plans to use the code anywhere but on Windows then there are still no
much point of doing that anyway.

[Mr Flibble]

Even if you are deploying on just a single OS a good layered design with
the appropriate abstractions should result in a lot of your code being
portable anyway so to ensure good design think portable code sausages!

/Flibble

[Mr Flibble]

When I am making a Qt GUI I don't scatter QString (which is UTF-16) all
over my code I only use it in my view (widget) code and I use
std::string (UTF-8) everywhere else and convert accordingly and to be
honest I have never experienced any performance issues with this
approach sausages.

/Flibble

[JiiPee]

On 14/01/2016 18:00, Richard wrote:
> [Please do not mail me a copy of your followup]
>
>

> People may be "Windows only programmers" and never touch MFC. (I hope to
> not have to touch MFC code ever again.)

I started MFC back in 1997. I found it easy/quick to learn. Also it has
a great support in Visual Studio community 2015 (free). VS is way better
than codeblocks or similar. I switched to codeblocks and wxWidgets for
1-2 years (because MFC was not free). But I found wxWidgets difficult to
learn and there is not much support for it.. .not many books about
wxWidgets neither. I did research those...i really wanted to learn it,
but it was difficult. So.... when VS was free , I was happy to go back
to MFC.

The thing to understand also is that if somebody has learned well MFC,
it does not make sense necessary to learn a new GUI, but rather keep
mastering what you already know well. Especially if you dont use GUI so
often. So that is another reason to stay with MFC.

I do not see wxWidgets or others much better than MFC. They might be
bettter, but I do not see essential difference in a basic use.

What is essentially better in wxWidgets compared to MFC? Also lets
remember MFC is done by Microsoff (who knows windows), but wxWidgets is
not. there might be some benefit there...

> Many "Windows only" programmers
> use wxWidgets or Qt because they are comprehensive UI frameworks that are
> freely available.

but Qt is not free, is it? there are a lot of people who would not pay .

> In desktop GUI application developers that I talk to,
> even "Windows only" developers, MFC has been losing mindshare steadily for
> years and years.

but I think its a matter of taste partly. You can very well create a
dialog box with MFC....and it looks and works the same as done with
wxWidgets. Most of the stuff done in GUI are very similar when done with
wxWidgets or MFC... the code even looks similar.

> The only developers I encounter that use MFC routinely
> are those that deal with legacy code bases that were written in MFC
> in the first place. Everyone else I talk to is using Qt or wxWidgets.
> YMMV, of course.

obviously if you need multiplatform stuff, then right tool needs to be
there. but like me am doing only windows programming currently.

[JiiPee]

On 16/01/2016 00:50, JiiPee wrote:
> On 14/01/2016 18:00, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>>
>> People may be "Windows only programmers" and never touch MFC. (I hope to
>> not have to touch MFC code ever again.)
>
> I started MFC back in 1997. I found it easy/quick to learn. Also it
> has a great support in Visual Studio community 2015 (free).

also there are tons of books written about VS and MFC but you dont find
that for wxWidgets. I think I found couple of wxWidgets books when i was
googling it....I really think this is a major problem with wxWidget:
books and support. one of the reasons I left it year ago.

[Öö Tiib]

On Saturday, 16 January 2016 02:51:15 UTC+2, JiiPee wrote:
> On 14/01/2016 18:00, Richard wrote:
>
> > Many "Windows only" programmers
> > use wxWidgets or Qt because they are comprehensive UI frameworks that are
> > freely available.
>
> but Qt is not free, is it? there are a lot of people who would not pay .

Most of Qt framework is available under free open source licenses.
http://doc.qt.io/qt-5/licensing.html For most needs LGPL is fine.
If you want to have Qt under commercial license then these are available
as well but such cost few thousands of euros.

[JiiPee]

But most of us we are doing commercial projects, I guess... this is not
my hobby only.

[Reinhardt Behm]

Even for commercial projects you can usually live with the LGPL, I do.

--
Reinhardt

[Vir Campestris]

On 14/01/2016 20:49, Christopher Pisz wrote:

I like to toss my code at different compilers purely because they have
different error checking. One may spot UB where another doesn't. I may
never _run_ it on the other compiler's code - just getting a clean
compile is nice.

Sadly I often don't get the chance.

I've had the pain of upgrading a major code base just from one version
of MSVC to another. As it turned out all the things it moaned about were
worth fixing.

Andy

[Öö Tiib]

So I have apparently to repeat what I wrote already above?
For most commercial projects usage of a library with LGPL is fine.
There are rather few commercial projects that for some odd reasons need
to modify public domain library code *AND* don't want to publish *THEIR*
modifications. For those on case of Qt there is option to pay few
thousand euros to Digia and then even that is legal.

[Richard]

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

n...@notvalid.com spake the secret code
<Otgmy.67684$AB2....@fx39.am4> thusly:

>What is essentially better in wxWidgets compared to MFC?

As with Qt, the essential difference is that wxWidgets/Qt applications
are portable to operating systems other than Windows.

>but Qt is not free, is it? there are a lot of people who would not pay .

Qt is free. You can purchase a commercial license to obtain other
benefits, but it is not required.

>> The only developers I encounter that use MFC routinely
>> are those that deal with legacy code bases that were written in MFC
>> in the first place. Everyone else I talk to is using Qt or wxWidgets.
>> YMMV, of course.
>
>obviously if you need multiplatform stuff, then right tool needs to be
>there. but like me am doing only windows programming currently.

Right. However, I would categorize you with the legacy code folks
that I mentioned. You invested in learning MFC so you want to
leverage that investment going forward.

My intent was not to open up the "MFC vs. other GUI frameworks"
debate, but to simply point out that there are many people programming
for Windows only that don't know or care about MFC for whatever
reason. For a long time the reason was that it wasn't freely available.

[Richard]

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

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

>I like to toss my code at different compilers purely because they have
>different error checking.

This is the point I was trying to make; sorry if that wasn't clear in
my earlier post on this thread.

>I've had the pain of upgrading a major code base just from one version
>of MSVC to another. As it turned out all the things it moaned about were
>worth fixing.

I've had a similar experience; everything whined about by various
compilers (and most things pointed out by static analyzers) were worth
fixing.

[JiiPee]

On 18/01/2016 18:00, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> n...@notvalid.com spake the secret code
> <Otgmy.67684$AB2....@fx39.am4> thusly:
>
>> What is essentially better in wxWidgets compared to MFC?
> As with Qt, the essential difference is that wxWidgets/Qt applications
> are portable to operating systems other than Windows.

ok, but what if somebody does only code for Windows?

>
>> but Qt is not free, is it? there are a lot of people who would not pay .
> Qt is free.

i understood its not totally free, but I guess you know....

> You can purchase a commercial license to obtain other
> benefits, but it is not required.
>
>>> The only developers I encounter that use MFC routinely
>>> are those that deal with legacy code bases that were written in MFC
>>> in the first place. Everyone else I talk to is using Qt or wxWidgets.
>>> YMMV, of course.
>> obviously if you need multiplatform stuff, then right tool needs to be
>> there. but like me am doing only windows programming currently.
> Right. However, I would categorize you with the legacy code folks
> that I mentioned. You invested in learning MFC so you want to
> leverage that investment going forward.

So far my clients have actually all used MFC, so good for me. And yes,
thats how I see it. But I dont work for big companies...

>
> My intent was not to open up the "MFC vs. other GUI frameworks"
> debate, but to simply point out that there are many people programming
> for Windows only that don't know or care about MFC for whatever
> reason. For a long time the reason was that it wasn't freely available.

yes for me also. I was using wxWidgets before just becouse of this. Well
I had VS2008 full version, but I did not want to start buying every
second year expensive new version. Luckyly somebody here mentioned its
free now, so jumped back to MFC ;).

I wonder if the VC2015 community remains free forever... there must be
some catch here?? It sounds too good to be true.

[JiiPee]

On 18/01/2016 18:00, Richard wrote:

> [Please do not mail me a copy of your followup]
>
> n...@notvalid.com spake the secret code
> <Otgmy.67684$AB2....@fx39.am4> thusly:
>
>> What is essentially better in wxWidgets compared to MFC?
> As with Qt, the essential difference is that wxWidgets/Qt applications
> are portable to operating systems other than Windows.
>

But I really like the VS interface.... all the debugging and other stuff
they work nice and just like I want them to work.
But seems to me that GCC compiler is better... maybe need to google if
its possible to nicely use VS with GCC compiler, hopefully its possible,
then could do DOS type of programs with GCC and windows with MFC.

[Richard]

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

n...@notvalid.com spake the secret code

<rGany.126056$a_7....@fx43.am4> thusly:

>On 18/01/2016 18:00, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> n...@notvalid.com spake the secret code
>> <Otgmy.67684$AB2....@fx39.am4> thusly:
>>
>>> What is essentially better in wxWidgets compared to MFC?
>> As with Qt, the essential difference is that wxWidgets/Qt applications
>> are portable to operating systems other than Windows.
>
>ok, but what if somebody does only code for Windows?

As mentioned earlier, even if you were programming Windows only
Qt/wxWidgets had the advantage of being free and open source. MFC is
now freely available, but it is still not open source. To some folks
that is an important difference.

>>> but Qt is not free, is it? there are a lot of people who would not pay .
>> Qt is free.
>
>i understood its not totally free, but I guess you know....

You can use the LGPL license or the commercial license. Rather than
trying to restate what Qt already says, I will simply point you at
their page that describes all this: <http://www.qt.io/FAQ/>

LGPL generally means that you can link against it without open
sourcing your application. (Which is why RMS hates the LGPL.)
<https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License>

>So far my clients have actually all used MFC, so good for me. And yes,
>thats how I see it. But I dont work for big companies...

Yes, there are *huge* amounts of MFC based applications out there. It
isn't going away anytime soon.

>I wonder if the VC2015 community remains free forever... there must be
>some catch here?? It sounds too good to be true.

As an MVP for 10 years I got to know how things operate within
Microsoft pretty well. The Visual Studio team and their products are
not considered a revenue producing product like Office, SQL Server or
Windows 10. Visual Studio is about developer mindshare to make it
nice and/or easy to develop applications for Windows. To the extent
that they charge anything for various bits of Visual Studio they weigh
that against the pressure it puts against it to decrease developer
mindshare because free trumps any price for many developers when it
comes to tooling.

Making MFC freely available means it is easier for more people to make
MFC based applications. That encourages more MFC based applications,
which is good for Windows as a platform.

So from that perspective, I wouldn't worry about MFC/ATL being taken away
as a free option now that they've made it available in Community
edition. To me it signals a competitive response in the "platform
wars" in that they think making MFC/ATL freely available encourages
more people to develop for Windows.

[Bo Persson]

On 2016-01-18 21:18, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> n...@notvalid.com spake the secret code
> <rGany.126056$a_7....@fx43.am4> thusly:
>
>> On 18/01/2016 18:00, Richard wrote:
>>> [Please do not mail me a copy of your followup]
>>>
>>> n...@notvalid.com spake the secret code
>>> <Otgmy.67684$AB2....@fx39.am4> thusly:
>>>
>>>> What is essentially better in wxWidgets compared to MFC?
>>> As with Qt, the essential difference is that wxWidgets/Qt applications
>>> are portable to operating systems other than Windows.
>>
>> ok, but what if somebody does only code for Windows?
>
> As mentioned earlier, even if you were programming Windows only
> Qt/wxWidgets had the advantage of being free and open source. MFC is
> now freely available, but it is still not open source. To some folks
> that is an important difference.
>

For some definition of "open source". :-)

The source IS provided with the compiler, but of course you are not
allowed to create your own branch.


Bo Persson

[Richard]

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

Bo Persson <b...@gmb.dk> spake the secret code
<dg5089...@mid.individual.net> thusly:

>On 2016-01-18 21:18, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> n...@notvalid.com spake the secret code
>> <rGany.126056$a_7....@fx43.am4> thusly:
>>
>>> On 18/01/2016 18:00, Richard wrote:
>>>> [Please do not mail me a copy of your followup]
>>>>
>>>> n...@notvalid.com spake the secret code
>>>> <Otgmy.67684$AB2....@fx39.am4> thusly:
>>>>
>>>>> What is essentially better in wxWidgets compared to MFC?
>>>> As with Qt, the essential difference is that wxWidgets/Qt applications
>>>> are portable to operating systems other than Windows.
>>>
>>> ok, but what if somebody does only code for Windows?
>>
>> As mentioned earlier, even if you were programming Windows only
>> Qt/wxWidgets had the advantage of being free and open source. MFC is
>> now freely available, but it is still not open source. To some folks
>> that is an important difference.
>
>For some definition of "open source". :-)

I'll use the Open Source Initiative's definition:
<http://opensource.org/osd>

MFC doesn't qualify as open source.

[Cholo Lennon]

On 01/18/2016 05:18 PM, Richard wrote:
> Making MFC freely available means it is easier for more people to make
> MFC based applications. That encourages more MFC based applications,
> which is good for Windows as a platform.

I thought MFC was dead (at least it was declared in that way several
times after 2000). In advance of that "dead", I switched my developments
to WTL in 2003. In 2005 I changed my domain to multi platform server
programming. After that I've never touched MFC code again.

Regards

--
Cholo Lennon
Bs.As.
ARG

[Vir Campestris]

On 18/01/2016 19:03, JiiPee wrote:
>
> I wonder if the VC2015 community remains free forever... there must be
> some catch here?? It sounds too good to be true.

The catch is your apps will only run on Windows, and you'll have learnt
to become a Windows programmer.

Andy

[Öö Tiib]

MFC did look rather awful year 2000. Icons and toolbar buttons were 16
color. Result looked like 1994 app. If I remember correctly that lasted
until 2008 when MFC was updated. Meanwhile some of MS own software did
have colorful look. Most developers did therefore dump MFC and rare did
ever look back.

[JiiPee]

Well its the main way to make windows programs in VS2015

[Richard]

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

n...@notvalid.com spake the secret code

<jzeny.152362$Yh.7...@fx36.am4> thusly:

>Well its the main way to make windows programs in VS2015

Wrong.

It is *a* way to make Windows programs in VS2015.

[seeplus]

On Tuesday, January 19, 2016 at 7:19:22 AM UTC+11, Richard wrote:
> [Please do not mail me a copy of your followup]
>

> Yes, there are *huge* amounts of MFC based applications out there. It
> isn't going away anytime soon.
>
> >I wonder if the VC2015 community remains free forever... there must be
> >some catch here?? It sounds too good to be true.
>
> As an MVP for 10 years I got to know how things operate within
> Microsoft pretty well. The Visual Studio team and their products are
> not considered a revenue producing product like Office, SQL Server or
> Windows 10.

Thanks for the insights.
That is indeed the way this MS business model seems to be organized.

I use MFC a lot and I am pleasantly surprised to see that in VS2015 UG1 they have done some work on some long standing niggling MFC problems.

Somebody at MS must still be working on it.

[Christopher Pisz]

Not even close.

I've been a programming Windows for 20 years without ever having to deal
with MFC and have been employed more than twice with the specific task
of completely removing it from existing code, in an effort to make the
software more maintainable. MFC is garbage IMO and I've thought it was
garbage since I made it through my third book on MFC, back when I was
learning to "program windows." It's got piss poor interfaces on classes
that are inherited from 20 other classes that have nothing to do with
the object you are after. I vomit every time I see the MFC icon.

I wish they'd differentiate somehow between C++ Windows Programmers and
C Programmers on Windows who use Hungarian notation and the 25 different
types that represent a string that MS made up along the way, the 5000
macros, and love to pass around void pointers and c-style cast them all
day long, on job postings.


--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---

[Christopher Pisz]

What does using Visual Studio have to do with being locked into using
MFC? Some editions of Visual Studio might have had some half-assed
visual editor tools included for silly dialogs and stuff, but you by no
means need to use MFC because you like Visual Studio. You can use any
GUI library you like.

and why does it seem to you that GCC is "better" and what metrics are
you using to come up with the adjective? I'm not sure how you even
compare the two when Visual Studio is an IDE and GCC is a compiler.

[Richard]

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

Christopher Pisz <nos...@notanaddress.com> spake the secret code

<n7jvsp$4o8$1...@dont-email.me> thusly:

>[...] MFC is garbage IMO and I've thought it was
>garbage since I made it through my third book on MFC, [...]

Egads, am I actually defending MFC? No, but understanding why MFC is
the way it is takes a bit of historical perspective. Personally I
like WTL for a pure Windows-only GUI. For cross-platform, I prefer
wxWidgets although I've been paid to do lots of Qt development.

MFC is a product of it's time -- 1992[1] -- and it shows. This was a time
when it was thought that "good class design" mean that all relationships
were expressed through inheritance with everything deriving from some
base CObject. The book "Design Patterns" <http://amzn.to/1V5GTiJ>
wouldn't be published for 2 more years. It was a very different time
for C++ when the full power of templates and how they manifest themselves
in a design wasn't well understood. It was a time when the C++ language
was newer and the standard library wasn't even a stable target.

ATL/WTL are an example of more modern C++ design, leveraging templates
so that you can obtain the benefits of abstraction without imposing a
giant class framework overhead. The motivation behind ATL was to
create a library for C++ that allowed you to create COM objects that
were minimal in size and it achieves that goal. WTL has been open
sourced by Microsoft and continues to evolve, although I'm surprised
they're still on sourceforge and haven't moved to github yet.
<http://wtl.sourceforge.net/>

The book "ATL Internals" <http://amzn.to/1n806VS> does a really good
job of explaining how the power of C++ and templates was used to create
this library. It is a stark contrast to the design philosophy present
in MFC. (Note: I read the 1st edition; the 2nd edition covers ATL 8.)

[1] <https://en.wikipedia.org/wiki/Microsoft_Foundation_Class_Library>

[Richard]

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

Vir Campestris <vir.cam...@invalid.invalid> spake the secret code

<JM-dnfjk6brqwgDL...@brightview.co.uk> thusly:

Nonsense.

You might as well say that using Eclipse CDT means your apps will only
run on linux and you'll have become a linux programmer.

Where your apps will run depends entirely on what kind of
code you write. If you care about portability, nothing in VS is
preventing you from embracing portability. But you know what? It's
your choice to embrace multi-platform or not.

If you think that platform myopia is unique to Windows programmers,
you've never attempted to take C++ software written in other environments
and bring it to Windows. Doing that enlightens you to the fact that
people who only use linux write just as much platform-specific (or
compiler-specific) code as anyone else.

[Ian Collins]

Richard wrote:
>
> If you think that platform myopia is unique to Windows programmers,
> you've never attempted to take C++ software written in other environments
> and bring it to Windows. Doing that enlightens you to the fact that
> people who only use linux write just as much platform-specific (or
> compiler-specific) code as anyone else.

Which is why I develop my embedded Linux (and occasional Windows) C++
code on Solaris :)

--
Ian Collins

[Vir Campestris]

On 19/01/2016 18:11, Richard wrote:
> Nonsense.
>
> You might as well say that using Eclipse CDT means your apps will only
> run on linux and you'll have become a linux programmer.
>
> Where your apps will run depends entirely on what kind of
> code you write. If you care about portability, nothing in VS is
> preventing you from embracing portability. But you know what? It's
> your choice to embrace multi-platform or not.
>

These days I do use Eclipse, and my apps are cross compiled to Android.

Mostly. I do miss the ease of use of Visual Studio, and it's a curse
that the Android build system really doesn't work well with Eclipse.
Though I suppose there aren't enough of us for anyone to care... And
yes, I do know I could fix it - given enough time.

> If you think that platform myopia is unique to Windows programmers,
> you've never attempted to take C++ software written in other environments
> and bring it to Windows. Doing that enlightens you to the fact that
> people who only use linux write just as much platform-specific (or
> compiler-specific) code as anyone else.

I suspect that myopia is the reason why STL files can (or is it could)
only be opened with a narrow char name. Doesn't map at all well to
Windows, but it's fine for Linux/Unix...

Andy

[Alf P. Steinbach]

On 1/19/2016 10:31 PM, Vir Campestris wrote:
>
> I suspect that myopia is the reason why STL files can (or is it could)
> only be opened with a narrow char name. Doesn't map at all well to
> Windows, but it's fine for Linux/Unix...

When Boost Filesystem becomes part of the standard library in C++17
(assuming it does), that's solved. Essentially, this part requires
*Windows* compilers to implement additional wide character support. IMHO
it's a disgrace to have such OS-specific requirements in the standard,
but still positive: something is better than nothing, surely.

At the moment, to e.g. make a Unixland-oriented library like OpenCV, or
the C++ standard library, open an arbitrary existing file in Windows,
one can use short 8+3 names: by default every Windows file has one.

Unfortunately Windows' support for short names can in principle be
turned off by the user, but one can simply not support systems where
that support is turned off.


Cheers,

- Alf

[Richard]

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

Vir Campestris <vir.cam...@invalid.invalid> spake the secret code

<VPKdnb72SqK3NgPL...@brightview.co.uk> thusly:

>On 19/01/2016 18:11, Richard wrote:
>> Nonsense.
>>
>> You might as well say that using Eclipse CDT means your apps will only
>> run on linux and you'll have become a linux programmer.
>>
>> Where your apps will run depends entirely on what kind of
>> code you write. If you care about portability, nothing in VS is
>> preventing you from embracing portability. But you know what? It's
>> your choice to embrace multi-platform or not.
>>
>These days I do use Eclipse, and my apps are cross compiled to Android.
>
>Mostly. I do miss the ease of use of Visual Studio, and it's a curse
>that the Android build system really doesn't work well with Eclipse.

VS 2015 added Android/iOS cross-platform support (MS even made their
own Android emulator, I believe). I haven't tried it, so I have no
idea how good it is. I'd like to hear from a regular Android
developer as to the quality of the implementation.

>I suspect that myopia is the reason why STL files can (or is it could)
>only be opened with a narrow char name. Doesn't map at all well to
>Windows, but it's fine for Linux/Unix...

For that one, I think it's a matter of who is writing proposals to
the standards committee and how passionate they are about making their
proposals part of the standard library. It looks like we're going to
get some version of boost::filesystem in the standard soon and I think
that addresses this shortcoming, but I am not certain.

[Jorgen Grahn]

On Mon, 2016-01-18, Richard wrote:
...

> LGPL generally means that you can link against it without open
> sourcing your application.

> (Which is why RMS hates the LGPL.)

[citation needed]

Sure, he tries to convince people to use the GPL instead:
https://www.gnu.org/licenses/why-not-lgpl.html

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Scott Lurndal]

Jorgen Grahn <grahn...@snipabacken.se> writes:
>On Mon, 2016-01-18, Richard wrote:
>...
>> LGPL generally means that you can link against it without open
>> sourcing your application.
>
>> (Which is why RMS hates the LGPL.)
>
>[citation needed]

see libreadline.


https://en.wikipedia.org/wiki/GNU_Readline#Choice_of_the_GPL_as_GNU_Readline.27s_license

[Jorgen Grahn]

On Tue, 2016-01-19, Vir Campestris wrote:
> On 19/01/2016 18:11, Richard wrote:

...

>> If you think that platform myopia is unique to Windows programmers,
>> you've never attempted to take C++ software written in other environments
>> and bring it to Windows. Doing that enlightens you to the fact that
>> people who only use linux write just as much platform-specific (or
>> compiler-specific) code as anyone else.
>
> I suspect that myopia is the reason why STL files can (or is it could)
> only be opened with a narrow char name. Doesn't map at all well to
> Windows, but it's fine for Linux/Unix...

What is an STL file -- do you mean e.g. a std::fstream, or a FILE*?

I don't think you need to look for a conspiracy. We all used 8-bit
character sets back in the 1990s, and all the APIs looked like that,
always had.

Then when it became fashionable to ask for more (around when Java
came, I suppose) pretty much everyone adopted utf-8, which didn't
require API changes. Microsoft didn't[0], and they weren't very
interested in C++ at the time[1] so I guess the standards people
weren't very interested in catering to them.

/Jorgen

[0] And perhaps they had good reasons, e.g. their work predated utf-8.
[1] Remember the many years when VC6 was the best they could offer?

[Ian Collins]

Jorgen Grahn wrote:
> [1] Remember the many years when VC6 was the best they could offer?

I wish people wouldn't keep reminding me, I'll have nightmares for a
week now...

--
Ian Collins

[Jorgen Grahn]

Sorry, I meant a citation for "RMS hates the LGPL".

[Mr Flibble]

VC6 has nothing to do with C++ sausages. Also, if you mention VC6 again
I am going to kill you.

/Flibble

[Richard]

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

Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
<slrnna00t6.5...@frailea.sa.invalid> thusly:

>On Wed, 2016-01-20, Scott Lurndal wrote:
>> Jorgen Grahn <grahn...@snipabacken.se> writes:
>>>On Mon, 2016-01-18, Richard wrote:
>>>...
>>>> LGPL generally means that you can link against it without open
>>>> sourcing your application.
>>>
>>>> (Which is why RMS hates the LGPL.)
>>>
>>>[citation needed]
>>
>> see libreadline.
>>
>>
>https://en.wikipedia.org/wiki/GNU_Readline#Choice_of_the_GPL_as_GNU_Readline.27s_license
>
>Sorry, I meant a citation for "RMS hates the LGPL".

It's my opinion. I cite my own brain.

[David Brown]

On 20/01/16 23:37, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
> <slrnna00t6.5...@frailea.sa.invalid> thusly:
>
>> On Wed, 2016-01-20, Scott Lurndal wrote:
>>> Jorgen Grahn <grahn...@snipabacken.se> writes:
>>>> On Mon, 2016-01-18, Richard wrote:
>>>> ...
>>>>> LGPL generally means that you can link against it without open
>>>>> sourcing your application.
>>>>
>>>>> (Which is why RMS hates the LGPL.)
>>>>
>>>> [citation needed]
>>>
>>> see libreadline.
>>>
>>>
>> https://en.wikipedia.org/wiki/GNU_Readline#Choice_of_the_GPL_as_GNU_Readline.27s_license
>>
>> Sorry, I meant a citation for "RMS hates the LGPL".
>
> It's my opinion. I cite my own brain.
>

My brain seconds your opinion. Basically, RMS dislikes the LGPL because
it makes it easier for other people to release code that is not free
(meaning his definition of "free as in speech, not free as in beer").
If a library is released under the LGPL, it lets people use it with
closed source (with dynamic linking or by releasing linkable object
files). If a library is released under the GPL, people have to use the
GPL throughout code that uses it. (It does not seem to have occurred to
RMS that people will often simply not use that library, and find
alternatives. People choose the licence for their source code for many
reasons - it is rare that the licence required by one specific library
is the overriding concern.)

But perhaps it is too strong to say that RMS /hates/ the LGPL - he
merely sees it as a poor choice and compromise, and wants people to use
the full GPL whenever possible.

[Öö Tiib]

LGPL was written by Richard Stallman himself to provide compromise
between GPL and permissive BSD/MIT. It may be that he hates making
compromises ... who knows.

[Öö Tiib]

On Wednesday, 20 January 2016 23:10:40 UTC+2, Jorgen Grahn wrote:
> On Tue, 2016-01-19, Vir Campestris wrote:
> > I suspect that myopia is the reason why STL files can (or is it could)
> > only be opened with a narrow char name. Doesn't map at all well to
> > Windows, but it's fine for Linux/Unix...
>
> What is an STL file -- do you mean e.g. a std::fstream, or a FILE*?
>
> I don't think you need to look for a conspiracy. We all used 8-bit
> character sets back in the 1990s, and all the APIs looked like that,
> always had.

Back in the 1980s file systems often used RADIX-50 for file names.
IOW not 8-bit but there was 3 characters in 16 bits. The roots of
case-insensitivity of Windows are likely in it.

[Vir Campestris]

On 20/01/2016 21:10, Jorgen Grahn wrote:
> What is an STL file -- do you mean e.g. a std::fstream, or a FILE*?
>

FILE* isn't STL, it's plain old C.

> I don't think you need to look for a conspiracy. We all used 8-bit
> character sets back in the 1990s, and all the APIs looked like that,
> always had.

Ah yes, I remember when we had to cope with EBCDIC. And then there were
the ICL 1900s, with 6 bit bytes... yes, filenames were so consistent
back then.

Also 1993 saw the release of Windows NT, with wide character APIs -
before, IIRC, there were any Unicode characters past 64k. Some of us
were using it.

Andy

[Robert Wessel]

On Thu, 21 Jan 2016 08:07:47 -0800 (PST), 嘱 Tiib <oot...@hot.ee>
wrote:

There were some OSs that used interesting packing schemes, especially
for file name extensions, but three radix-50 characters don't fit in
16 bits. The limit would be three radix-40 characters, or a mixed
representation that had restrictions on character combinations.

[Jorgen Grahn]

On Thu, 2016-01-21, Vir Campestris wrote:
> On 20/01/2016 21:10, Jorgen Grahn wrote:
>> What is an STL file -- do you mean e.g. a std::fstream, or a FILE*?
>>
> FILE* isn't STL, it's plain old C.

But std::fstream isn't STL either, so I still don't know what you
mean.

>> I don't think you need to look for a conspiracy. We all used 8-bit
>> character sets back in the 1990s, and all the APIs looked like that,
>> always had.
>
> Ah yes, I remember when we had to cope with EBCDIC. And then there were
> the ICL 1900s, with 6 bit bytes... yes, filenames were so consistent
> back then.

Did any of them have C++ implementations which anyone cared about? Of
course I'm not saying /everyone/ used APIs where a const char* was a
reasonable way to represent a file name, but it was very widely spread
and obviously there was enough of a mapping to support C++ on top of
it, for machines where anyone was interested.

My point is, it's not just Linux bias. At the time I used AmigaDOS
and believed iso8859-1 was the way of the future (and to hell with
anyone who thought they needed more).

> Also 1993 saw the release of Windows NT, with wide character APIs -
> before, IIRC, there were any Unicode characters past 64k. Some of us
> were using it.

I'm not claiming you didn't. Even I used Windows NT 4.0 in the late
1990s, although not with wide characters. Perhaps the C++ community
just ignored the problem until utf-8 came along and made it a non-
issue for a lot of people? After all, that's what I did myself.

/Jorgen

[Öö Tiib]

On Friday, 22 January 2016 00:02:44 UTC+2, robert...@yahoo.com wrote:
> On Thu, 21 Jan 2016 08:07:47 -0800 (PST), Öö Tiib <oot...@hot.ee>

There are AFAIK no such thing as "Radix-40". The term "Radix-50" means
that there are 40 characters. The "50" in its name is octal number.
Blame who named it, wasn't me. Terms mean what those mean, (not what
you think those mean) and so 3 Radix-50 characters fit into 16 bits.

[Alf P. Steinbach]

On 1/22/2016 8:21 AM, Öö Tiib wrote:
>
> There are AFAIK no such thing as "Radix-40". The term "Radix-50" means
> that there are 40 characters. The "50" in its name is octal number.
> Blame who named it, wasn't me. Terms mean what those mean, (not what
> you think those mean) and so 3 Radix-50 characters fit into 16 bits.
>

https://en.wikipedia.org/wiki/DEC_Radix-50

“The actual encoding differed between the 36-bit and 16-bit systems”

Hah, good joke. :)

A modern variant is Windows' [1] GetProcAddress API function, whose
argument, if it is a text string, is encoded as Windows ANSI, which at
least for other functions depends on the configuration of the system the
program runs on. And if so (the details are now undocumented stuff),
then for the general case hardcoded literals won't work. It's all the
more baffling as the data structures it accesses use UTF-8...


Cheers,

- Alf

Notes:
[1] <url:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683212%28v=vs.85%29.aspx>

[Paavo Helde]

On 22.01.2016 12:27, Alf P. Steinbach wrote:
> A modern variant is Windows' [1] GetProcAddress API function, whose
> argument, if it is a text string, is encoded as Windows ANSI, which at
> least for other functions depends on the configuration of the system the
> program runs on. And if so (the details are now undocumented stuff),
> then for the general case hardcoded literals won't work. It's all the
> more baffling as the data structures it accesses use UTF-8...

This is most interesting, care to provide some links (about the UTF-8
connotations)? I had an impression GetProcAddress deals with mangled
linker symbols which I assumed are normalized to ASCII anyway, aren't they?

Cheers
Paavo

[Alf P. Steinbach]

The data structures are well documented, but AFAIK the encodings are
not. Mangling and using ASCII could have worked, with some special
mangle convention for non-ASCII characters. But it's just UTF-8 for the
characters, plus by default mangling to encode the signature etc..

I found out about the UTF-8 encoding once when I coded up some traversal
of the structures for an SO answer, but my google-foo now fails me: I
can't find it again.

But here's a simple example, using Microsoft's toolchain. Here `chcp` is
a command to change the console window's active codepage, cl is the
Visual C++ compiler, probably named for its ancestor Lattice C, and
dumpbin is Microsofts binary dump utility, corresponding to gcc's
objdump. And as you can see, under the assumption that dumbin dumps the
raw bytes of the name (and yes it does), the name is UTF-8 encoded:


<example>
C:\my\forums\clc++\018> chcp 1252
Active code page: 1252

C:\my\forums\clc++\018> type dll.cpp
#include <windows.h>

__declspec( dllexport )
void bare_blåbærtøys()
{ MessageBoxW( 0, L"Oi", L"Message:", MB_SETFOREGROUND ); }

C:\my\forums\clc++\018> type name_in_utf8.txt
bare_blåbærtøys

C:\my\forums\clc++\018> cl dll.cpp user32.lib /LD
dll.cpp
Creating library dll.lib and object dll.exp

C:\my\forums\clc++\018> dumpbin /exports dll.dll | find "bare"
1 0 00001260 ?bare_blåbærtøys@@YAXXZ

C:\my\forums\clc++\018> _
</example>


• • •

Standard C++ allows the Norwegian Æ, Ø and Å (lowercase æ, ø, and å) in
identifiers, as used above, but g++ doesn't accept them, at least not by
default :( :


<example>
C:\my\forums\clc++\018> g++ -c dll.cpp -finput-charset=cp1252
dll.cpp:4:1: error: stray '\303' in program
void bare_blåbærtøys()
^
dll.cpp:4:1: error: stray '\245' in program
dll.cpp:4:1: error: stray '\303' in program
dll.cpp:4:1: error: stray '\246' in program
dll.cpp:4:1: error: stray '\303' in program
dll.cpp:4:1: error: stray '\270' in program
dll.cpp:4:15: error: expected initializer before 'b'
void bare_blåbærtøys()
^

C:\my\forums\clc++\018> g++ --version | find "++"
g++ (tdm64-1) 5.1.0

C:\my\forums\clc++\018> _
</example>


There are no errors (i.e. MinGW g++ understands the Microsoft `declspec`
directive) when the file only contains ASCII characters. I'm at a loss
at how the compiler ends up with the specific values in the error
messages. They are not the raw encoding values, but there are only three
distinct values, presumably corresponding to æ, ø and å, and they look
as if they're scooped from a translation to UTF-8.

Anyway, due to g++'s lack of support for non-ASCII function names, I
can't show the DLL example with the GNU toolchain, sorry.

Cheers & hth.,

Alf

[Paavo Helde]

Wow, it seems for once Microsoft has made a sane decision about software
design! Of course this does not align well with their corporate image,
so they have left it hidden and undocumented ;-)