"Current Proposals for C++17"

[Lynn McGuire]

"Current Proposals for C++17"
https://meetingcpp.com/index.php/br/items/current-proposals-for-c17.html

"There is a new batch of proposals for C++17, published for next weeks ISO C++ Committee meeting in Jacksonville, Florida. With way
over 100 proposals, and limited time, I will try to cover in this posting only papers which have C++17 in their title, which gives a
fairly random selection with a few highlights. A first overview gives you my listing by c++ committee subgroups or the original ISO
listing at open-std.org. Currently C++17 is still in the making, each committee meeting will set new trends and add features likely
to the standard. But lets have a look at some of the proposals. I'll go by the order of my subgroup listing."

A detailed list of proposals by paper is at:
http://meetingcpp.com/index.php/id-2016-proposals-by-mailing-and-subgroup.html

There is a standard 2D graphical library proposal at:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0267r0.pdf

There is not a standard user interface toolkit proposal.

Bummer.

Lynn

[Victor Bazarov]

On 2/26/2016 5:40 PM, Lynn McGuire wrote:
> "Current Proposals for C++17"
> [...]

>
> There is not a standard user interface toolkit proposal.
>
> Bummer.

What?!! You mean *yours* was discarded? Outrageous!

V
--
I do not respond to top-posted replies, please don't ask

[Mr Flibble]

On 26/02/2016 22:40, Lynn McGuire wrote:
>
> There is not a standard user interface toolkit proposal.

There never will be one either as nobody will be able to agree on what
one should look like.

/Flibble

[Richard]

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

Lynn McGuire <l...@winsim.com> spake the secret code
<naqk3a$s2i$1...@dont-email.me> thusly:

>There is not a standard user interface toolkit proposal.

Don't need it.

There are already several good defacto standards: Qt, wxWidgets, and
(less to my personal taste, but relevant) MFC. Where "good" is defined
from various perspectives including, but not limited to, freely available,
actively improved, proven viability in the marketplace and portable among
platforms.

C doesn't have it.
Python doesn't have it.
JavaScript doesn't have it.
NodeJS doesn't have it.
FORTRAN doesn't have it.
Java doesn't have it.
C# doesn't have it.

Why people are insistent on trying to jam every possible library into
the standard is beyond me. Before trying to make the C++ Standard
Library the union of all available libraries on the internet, how
about we sovle the dependency and package system in a reasonable way?

Hell, how about we get modules deployed and widely used?

Either of those is way more fucking[*] important than a UI library in
the standard.

[*] This one's for you, woodbrain77.
--
"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>

[Alf P. Steinbach]

On 27.02.2016 01:54, Richard wrote:
> Lynn McGuire <l...@winsim.com> spake the secret code
> <naqk3a$s2i$1...@dont-email.me> thusly:
>
>> There is not a standard user interface toolkit proposal.
>
> Don't need it.
>
> There are already several good defacto standards: Qt, wxWidgets, and
> (less to my personal taste, but relevant) MFC. Where "good" is defined
> from various perspectives including, but not limited to, freely available,
> actively improved, proven viability in the marketplace and portable among
> platforms.
>
> C doesn't have it.

Right.

> Python doesn't have it.

Well, CPython ships with Tk/Inter (I think it was called). Which is
standard in the sense that it's always there, as a basic GUI.

> JavaScript doesn't have it.

Oh, for JavaScript it's just HTML.

> NodeJS doesn't have it.

An embarrassment of riches. First of course basic HTML, both on the web,
in web apps (including Android phone apps), and e.g. Windows HTML
applications (old but still going technology). But then also the two
variants of whatever it was called, that was used to build the editor,
that the Microsoft "Code" editor is based on (and still uses that).

Sorry I'm not more clear on this. I could research it. In fact that's
the plan, but I'm not there yet. :(

> FORTRAN doesn't have it.
> Java doesn't have it.

Well, at first Java had AWT, and then Swing built on AWT. At which
point, as I recall, they changed the namespaces, breaking lots and lots
of code. Infuriating.

> C# doesn't have it.

C# is like NodeJS, just too many GUI toolkits now. But the main basic C#
GUI stuff is Windows Forms. I believe Mono has Windows Forms support?

> Why people are insistent on trying to jam every possible library into
> the standard is beyond me. Before trying to make the C++ Standard
> Library the union of all available libraries on the internet, how
> about we sovle the dependency and package system in a reasonable way?
>
> Hell, how about we get modules deployed and widely used?

Good ideas all, I agree.

And there is already experimental support for modules in Visual C++.

Which reminds me to try that out! :)

But I think that one should start at the absolutely first little thing
that one needs to deal with to do C++ programming. And that is of course
the `main` function. Happily Microsoft recently informed me they'll fix
their lack of direct support for standard `main` in GUI subsystem
programs, in some forthcoming release. Well, at least I chose to
interpret the wording that way. But [1]judge for yourself. :)

Then, I think it would be nice to get basic type support in place, in
particular character encoding value types and ditto string literals, as
in my work-in-progress [2]cppx library, or thereabouts. Well not just
international text handling support, but also, hm, dates!, and a decimal
type sufficient for handling national scale monetary amounts, and,
little things like getting -- for Pete's sake -- [3]a `std::pi` constant!

It's all the little stuff that makes the language usable.

Having each project and person reinvent the wheel again and again and
again, is IMHO sub-optimal. Well the Poco library does some of this. But
for some reason I've never used Poco -- have any reader?


> Either of those is way more [expletive removed] important than a UI
> library in the standard.

Yes I agree. :)


Cheers!,

- Alf


Notes:
[1] <url:
https://connect.microsoft.com/VisualStudio/feedback/details/2128262/missing-c-11-standard-macro-stdc-hosted>
[2] <url: http://alf-p-steinbach.github.io/cppx/>
[3] `M_PI` is already de facto standard, but not part of the C++
standard. It surprised me, once, to realize how much innovation the
committee's been doing, while /not/ standardizing widely used existing
practice. Anyway, more info: <url:
http://stackoverflow.com/questions/1727881/how-to-use-the-pi-constant-in-c>

[David Brown]

On 27/02/16 05:19, Alf P. Steinbach wrote:
> On 27.02.2016 01:54, Richard wrote:
>> Lynn McGuire <l...@winsim.com> spake the secret code

>> Why people are insistent on trying to jam every possible library into
>> the standard is beyond me. Before trying to make the C++ Standard
>> Library the union of all available libraries on the internet, how
>> about we sovle the dependency and package system in a reasonable way?
>>
>> Hell, how about we get modules deployed and widely used?
>
> Good ideas all, I agree.
>
> And there is already experimental support for modules in Visual C++.

Unfortunately, I think they are significantly different from the
experimental modules in clang. I wish they would get this one sorted
out, so that we can have a single proper module feature for C++.

[Öö Tiib]

Experimental implementation is not carved into rock and its makers
knew that it has to be likely rewritten. People who used such for
real product knew with what they risk.

I am more worried that adding innovations like Modules, Concepts and
Reflection at once will cause serious headache of integrating those
features into whole.

[Dombo]

Op 27-Feb-16 om 5:19 schreef Alf P. Steinbach:

> On 27.02.2016 01:54, Richard wrote:
>> Lynn McGuire <l...@winsim.com> spake the secret code
>> <naqk3a$s2i$1...@dont-email.me> thusly:
>>
>>> There is not a standard user interface toolkit proposal.
>>
>> Don't need it.
>>
>> There are already several good defacto standards: Qt, wxWidgets, and
>> (less to my personal taste, but relevant) MFC. Where "good" is defined
>> from various perspectives including, but not limited to, freely
>> available, actively improved, proven viability in the marketplace and portable among
>> platforms.

Unfortunately those user interface kits are showing their age; they
don't take advantage of modern C++ features but instead choose to supply
their own string, container...etc classes and mechanisms. All of this
was understandable in the nineties before C++ was standardized but is
unforgivable in this day and age.

It would be nice to have a multi platform widely used GUI toolkit that
takes advantage of modern C++ and that smoothly interfaces with the
standard library.

[snip]

>> C# doesn't have it.
>
> C# is like NodeJS, just too many GUI toolkits now. But the main basic C#
> GUI stuff is Windows Forms. I believe Mono has Windows Forms support?

Development of WinForms has stopped well over a decade ago, nowadays WPF
is pretty much the way to go. Besides those two I don't know of any
other widely used GUI toolkit in the .NET world.

[Öö Tiib]

On Saturday, 27 February 2016 20:41:05 UTC+2, Dombo wrote:
> Op 27-Feb-16 om 5:19 schreef Alf P. Steinbach:
> > On 27.02.2016 01:54, Richard wrote:
> >> Lynn McGuire <l...@winsim.com> spake the secret code
> >> <naqk3a$s2i$1...@dont-email.me> thusly:
> >>
> >>> There is not a standard user interface toolkit proposal.
> >>
> >> Don't need it.
> >>
> >> There are already several good defacto standards: Qt, wxWidgets, and
> >> (less to my personal taste, but relevant) MFC. Where "good" is defined
> >> from various perspectives including, but not limited to, freely
> >> available, actively improved, proven viability in the marketplace and portable among
> >> platforms.
>
> Unfortunately those user interface kits are showing their age; they
> don't take advantage of modern C++ features but instead choose to supply
> their own string, container...etc classes and mechanisms. All of this
> was understandable in the nineties before C++ was standardized but is
> unforgivable in this day and age.

It is actually good. It makes clear interface where your program logic
layer (that does not use UI classes) touches with UI (that does not
use standard library).

Standard C++ has weak and full of "implementation-defined" features
regarding unicode, locales etc. This day and age we have to either:
a) accept having files with names full of garbage, show different
garbage instead of text on each platform and also format numbers
(nothing to talk of money, date and time) in unpredictable way;
b) write significant amount of portability code to deal with it;
c) use platform-specific API calls;
d) use those QStrings and QLocales that already deal with it.

>
> It would be nice to have a multi platform widely used GUI toolkit that
> takes advantage of modern C++ and that smoothly interfaces with the
> standard library.

I like harshly interfacing GUI. I dislike code where program logic is
intermixed with GUI and I congratulate GUI toolkit that makes it as
painful as possible for those who let so different responsibilities
to diffuse all over the code base.

[woodb...@gmail.com]

On Friday, February 26, 2016 at 6:54:39 PM UTC-6, Richard wrote:

Richard,

Please don't swear here.

Brian
Ebenezer Enterprises
http://webEbenezer.net

[Mr Flibble]

On 28/02/2016 01:25, woodb...@gmail.com wrote:
> On Friday, February 26, 2016 at 6:54:39 PM UTC-6, Richard wrote:
>
> Richard,
>
> Please don't swear here.

'This video may contain sexual swearwords, I'm afraid. There are 28
'fucks'. Including that one 29. Ah, fuck it, make it 30.' -- Paul Calf

https://www.youtube.com/watch?v=42UCpOzTbNU

/Flibble

[Gareth Owen]

"As such this video may contain frequent sexual swearwords, such as
bollocks, and wanke..." https://www.youtube.com/watch?v=15niBO3ZaQo

[Christian Gollwitzer]

Am 28.02.16 um 02:25 schrieb woodb...@gmail.com:

> On Friday, February 26, 2016 at 6:54:39 PM UTC-6, Richard wrote:
>
> Richard,
>
> Please don't swear here.
>

I don't understand, why you oppose against fucking. It is the one thing
through which we all were made. It is scientifically proven the cause of
all our being.

Christian

[David Brown]

On 27/02/16 17:45, 嘱 Tiib wrote:
> On Saturday, 27 February 2016 15:41:31 UTC+2, David Brown wrote:
>> On 27/02/16 05:19, Alf P. Steinbach wrote:
>>> On 27.02.2016 01:54, Richard wrote:
>>>> Lynn McGuire <l...@winsim.com> spake the secret code
>>
>>>> Why people are insistent on trying to jam every possible library into
>>>> the standard is beyond me. Before trying to make the C++ Standard
>>>> Library the union of all available libraries on the internet, how
>>>> about we sovle the dependency and package system in a reasonable way?
>>>>
>>>> Hell, how about we get modules deployed and widely used?
>>>
>>> Good ideas all, I agree.
>>>
>>> And there is already experimental support for modules in Visual C++.
>>
>> Unfortunately, I think they are significantly different from the
>> experimental modules in clang. I wish they would get this one sorted
>> out, so that we can have a single proper module feature for C++.
>
> Experimental implementation is not carved into rock and its makers
> knew that it has to be likely rewritten. People who used such for
> real product knew with what they risk.
>

Yes, there is a bit of trial-and-error here to see what works in
practice. Some people will like the idea enough to risk using the
experimental versions - and their feedback will help shape the final
versions. I understand that this will take time - but I hope it will
not be long before a final agreed version can be made.

> I am more worried that adding innovations like Modules, Concepts and
> Reflection at once will cause serious headache of integrating those
> features into whole.
>

Certainly modules and concepts are being tried out as experimental
features in compilers - hopefully that means they will be reasonably
good when they make the standards. It would be unfortunate if they were
added and then found to have some fundamental problem.

[Öö Tiib]

On Sunday, 28 February 2016 17:44:09 UTC+2, David Brown wrote:

> On 27/02/16 17:45, Öö Tiib wrote:
>
> > I am more worried that adding innovations like Modules, Concepts and
> > Reflection at once will cause serious headache of integrating those
> > features into whole.
> >
>
> Certainly modules and concepts are being tried out as experimental
> features in compilers - hopefully that means they will be reasonably
> good when they make the standards. It would be unfortunate if they were
> added and then found to have some fundamental problem.

I wonder if anyone is trying all the three at once? Integration involves
always issues, rough edges and dim corners. Dealing with those may add
complexities and complexities may be in conflict with faster and
better scalable builds, better diagnostics, easier definition checking,
more transparency, better structure, better type-safety (IOW the
motivation of adding those features).

[Juha Nieminen]

Richard <legaliz...@mail.xmission.com> wrote:
> Why people are insistent on trying to jam every possible library into
> the standard is beyond me.

That got me thinking: There are many things that do not really belong
into the C++ standard, but are nevertheless things that would be very
useful and people often request.

Perhaps a kind of compromise could work: A "secondary" specification
defined by the standard committee, of optional libraries. In other words,
libraries that a standard-conforming compiler is not forced to implement,
but if it does, then it has to implement it as specified (so that all
programs written to use said library will compile and work).

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Mr Flibble]

Interesting that "wanker" is acceptable on the BBC whilst, I think,
"cunt" is not but this is probably due to the fact that "cunt" is the
strongest swear word in the English language. ITV dubbed out the "cunt"
in "Can I get any of you cunts a drink?" when they showed Shaun Of The
Dead once.

/Flibble

[Gareth Owen]

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

> Interesting that "wanker" is acceptable on the BBC whilst, I think,
> "cunt" is not but this is probably due to the fact that "cunt" is the
> strongest swear word in the English language.

Well, there's no flat list of "allowed v. not allowed". The context is
taken into consideration. I do remember ITV once replacing the word
"Penis" with "Twinkie" in Ghostbusters, tho.

[Dombo]

Op 27-Feb-16 om 20:23 schreef Öö Tiib:

> On Saturday, 27 February 2016 20:41:05 UTC+2, Dombo wrote:
>> Op 27-Feb-16 om 5:19 schreef Alf P. Steinbach:
>>> On 27.02.2016 01:54, Richard wrote:
>>>> Lynn McGuire <l...@winsim.com> spake the secret code
>>>> <naqk3a$s2i$1...@dont-email.me> thusly:
>>>>
>>>>> There is not a standard user interface toolkit proposal.
>>>>
>>>> Don't need it.
>>>>
>>>> There are already several good defacto standards: Qt, wxWidgets, and
>>>> (less to my personal taste, but relevant) MFC. Where "good" is defined
>>>> from various perspectives including, but not limited to, freely
>>>> available, actively improved, proven viability in the marketplace and portable among
>>>> platforms.
>>
>> Unfortunately those user interface kits are showing their age; they
>> don't take advantage of modern C++ features but instead choose to supply
>> their own string, container...etc classes and mechanisms. All of this
>> was understandable in the nineties before C++ was standardized but is
>> unforgivable in this day and age.
>
> It is actually good. It makes clear interface where your program logic
> layer (that does not use UI classes) touches with UI (that does not
> use standard library).

If mixing UI and program logic is really a big concern and you cannot
rely on the discipline of the developers you'd much better of using
another programming language for the UI.

> Standard C++ has weak and full of "implementation-defined" features
> regarding unicode, locales etc. This day and age we have to either:
> a) accept having files with names full of garbage, show different
> garbage instead of text on each platform and also format numbers
> (nothing to talk of money, date and time) in unpredictable way;
> b) write significant amount of portability code to deal with it;
> c) use platform-specific API calls;
> d) use those QStrings and QLocales that already deal with it.
>
>>
>> It would be nice to have a multi platform widely used GUI toolkit that
>> takes advantage of modern C++ and that smoothly interfaces with the
>> standard library.
>
> I like harshly interfacing GUI. I dislike code where program logic is
> intermixed with GUI and I congratulate GUI toolkit that makes it as
> painful as possible for those who let so different responsibilities
> to diffuse all over the code base.

I'm all for keeping a clear separation between UI and business logic.
But there are better ways to accomplish that than introducing
incompatible types. Making interfacing with the standard library
unnecessarily hard just stimulates people to just do everything in the
UI code to avoid having to write error-prone/no-added-value glue code to
interface with other parts of the program.

And lets be honest; keeping the UI code separate from business logic is
not the reason why those GUI toolkits have their own string and
container classes. Just look at Qt, it is (unfortunately) not just a GUI
library, but provides classes for just about anything they could think
of, including lots of stuff that has absolutely nothing to do with UI.
And guess what; those non-UI classes use the same string types and
container types as used for the GUI part, apparently Qt didn't thought
it was necessary to introduce more incompatible string and container
classes to make the distinction between UI and business logic clear.

One of the things that separates C++ from other modern programming
languages is the inconsistent mess of (naming) conventions, strings,
containers...etc you get confronted with if you use multiple libraries
from various sources. Not a good thing in my book.

[Ian Collins]

Before or after The Thick of It?

This one is still hard to best:

https://www.youtube.com/watch?v=JaY7VTftPdY

--
Ian Collins

[Geoff]

I think this might go back to the myth of Adam and Eve and original
sin. They were both given life without fucking being involved. Then
they ate of the tree of knowledge and were both fucked from that day
forward. Damned by God and driven from Eden, it's now a sin in the
eyes of religious fanatics to eat the wrong foods, fuck, wank off,
fuck thy neighbor's wife or do anything you fucking like of which the
pious might disapprove.

[Öö Tiib]

Good idea, typically HTML5 is best candidate now. Maybe in few years C++
again built with asm.js. Qt 5 has also now gone to separate language
for GUI with its QML. Unfortunately that makes 3 layers: application
logic, fishbones of that Qt and QML.

>
> > Standard C++ has weak and full of "implementation-defined" features
> > regarding unicode, locales etc. This day and age we have to either:
> > a) accept having files with names full of garbage, show different
> > garbage instead of text on each platform and also format numbers
> > (nothing to talk of money, date and time) in unpredictable way;
> > b) write significant amount of portability code to deal with it;
> > c) use platform-specific API calls;
> > d) use those QStrings and QLocales that already deal with it.
> >
> >>
> >> It would be nice to have a multi platform widely used GUI toolkit that
> >> takes advantage of modern C++ and that smoothly interfaces with the
> >> standard library.
> >
> > I like harshly interfacing GUI. I dislike code where program logic is
> > intermixed with GUI and I congratulate GUI toolkit that makes it as
> > painful as possible for those who let so different responsibilities
> > to diffuse all over the code base.
>
> I'm all for keeping a clear separation between UI and business logic.
> But there are better ways to accomplish that than introducing
> incompatible types. Making interfacing with the standard library
> unnecessarily hard just stimulates people to just do everything in the
> UI code to avoid having to write error-prone/no-added-value glue code to
> interface with other parts of the program.

What are the better ways? I sometimes suggest separate processes for
UI and business logic but that makes interfacing even harsher so I
don't think you meant that.

The product gets actually produced quicker that way since UI-less
application logic is easier to unit test and automatic test and any
peck or panic about UI features does not accidentally screw
application logic up. It is not hard to sell such architecture to
shareholders since there is prospect to put business logic into
"cloud", UI into "web" or "apps" or whatever the current buzzwords
are.

>
> And lets be honest; keeping the UI code separate from business logic is
> not the reason why those GUI toolkits have their own string and
> container classes. Just look at Qt, it is (unfortunately) not just a GUI
> library, but provides classes for just about anything they could think
> of, including lots of stuff that has absolutely nothing to do with UI.
> And guess what; those non-UI classes use the same string types and
> container types as used for the GUI part, apparently Qt didn't thought
> it was necessary to introduce more incompatible string and container
> classes to make the distinction between UI and business logic clear.

I agree. There is odd megalomania on case of Qt. Most things that Qt
incorporates besides GUI are not hard to dump however. Those have
better alternatives freely available.

>
> One of the things that separates C++ from other modern programming
> languages is the inconsistent mess of (naming) conventions, strings,
> containers...etc you get confronted with if you use multiple libraries
> from various sources. Not a good thing in my book.

That is very same with other languages as well. Everybody wants to
have some personal "style". More like samurais than engineers.

[Daniel]

On Sunday, February 28, 2016 at 3:19:24 AM UTC-5, Christian Gollwitzer wrote:
> Am 28.02.16 um 02:25 schrieb woodb...@gmail.com:
> >

> > Please don't swear here.
> >
> I don't understand, why you oppose against fucking.

Just guessing, but I don't think he's objecting to the word as such, I think
what he's objecting to is the dilution of the word, such as in "Fuck!" after
hitting your thumb with a hammer. The counter argument, of course, is that
research shows that the hypoalgesic effect of swearing can help reduce the
sensation of pain, c.f https://en.wikipedia.org/wiki/Hypoalgesic_effect_of_swearing.

Daniel

[David Brown]

You mean you think he'd be happy with swear words as long as they are
used solely for their literal meanings? I believe that would apply to
religious terms - I'm sure he has nothing against saying "Jesus" in
church, while objecting to its use as a hypoalgesic. I really don't
think that applies to "fuck", however.

No, I think Brian just has a particularly extreme view on swearing out
of context. Most of us have unwritten rules as to when we think
swearing is appropriate or not. When we watch a stand-up comedian, we
expect a good deal of colourful language. But we would be surprised to
hear a newsreader tell us "the economy has gone to fuck", even if it is
a clear, accurate and easily understood news item. And I think most of
us here feel that Usenet posts typically don't warrant the emphasis of
swearing - but the occasional light swear is fine. There are other
newsgroups were some posters are, quite frankly, unpleasant to read.

What distinguishes Brian is that he invariably reacts with a pointless
complaint for every tiny swear word that is usually unnoticed by anyone
else. And his complaints are invariably followed by someone else adding
more swearing, just to bug him - he never seems to learn, and his
complaint posts are far more annoying than any swearing in this newsgroup.

[Alf P. Steinbach]

On 29.02.2016 09:04, David Brown wrote:
> [snip] his complaints are invariably followed by someone else adding

> more swearing, just to bug him - he never seems to learn,

There is the question of who is training whom. Pavlov's dog trained
Pavlov to ring a bell at feeding time. As a reward to Pavlov the dog
simply salivated each time Pavlov rang the bell at feeding time, and
after a few weeks or months Pavlov would ring the bell /every/ feeding time.

But while psychologists are so easy to train that even a quite famous
one could be trained by a dog, programmers who are Usenet denizens...

Well. Still. The question is open.


Cheers,

- Alf

[Daniel]

On Monday, February 29, 2016 at 5:21:41 AM UTC-5, Alf P. Steinbach wrote:

> Pavlov's dog trained Pavlov to ring a bell at feeding time. As a reward to
> Pavlov the dog simply salivated each time Pavlov rang the bell at feeding

> time.
>
As my background is in economics, I've always viewed the behavior of Skinner
and his rat as a freely entered into agreement: I'll give you food pellets
in exchange for you pull on a lever. I prefer that interpretation to that of
stimulus-responsibus.

> But while psychologists are so easy to train

My sister tells me that her psychology classmates successfully trained their
professor to stop pacing at the lectern, by putting down their notebooks and
pens and affecting disinterest whenever she stepped beyond a prescribed
boundary. Over time they narrowed the boundary, until stationary.

Daniel

[Scott Lurndal]

Lynn McGuire <l...@winsim.com> writes:
>"Current Proposals for C++17"
> https://meetingcpp.com/index.php/br/items/current-proposals-for-c17.html

Ah, such lovely thinking:

"Also, it shows that the committee is willing to not only add things, but also to deprecate,
and remove and break things in the future. Which is great..."

[red floyd]

Sort of like the various "annexes" to the Ada spec?

[red floyd]

On 2/29/2016 2:46 AM, Daniel wrote:

> My sister tells me that her psychology classmates successfully trained their
> professor to stop pacing at the lectern, by putting down their notebooks and
> pens and affecting disinterest whenever she stepped beyond a prescribed
> boundary. Over time they narrowed the boundary, until stationary.
>

I thought that was an urban legend. I've seen it many times on
the net.

[Richard]

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

Dombo <do...@disposable.invalid> spake the secret code
<nasqe0$vgd$1...@dont-email.me> thusly:

>Op 27-Feb-16 om 5:19 schreef Alf P. Steinbach:
>> On 27.02.2016 01:54, Richard wrote:
>>> Lynn McGuire <l...@winsim.com> spake the secret code
>>> <naqk3a$s2i$1...@dont-email.me> thusly:
>>>
>>>> There is not a standard user interface toolkit proposal.
>>>
>>> Don't need it.
>>>
>>> There are already several good defacto standards: Qt, wxWidgets, and

>>> (less to my personal taste, but relevant) MFC. [...]

>
>Unfortunately those user interface kits are showing their age; they
>don't take advantage of modern C++ features but instead choose to supply
>their own string, container...etc classes and mechanisms. All of this
>was understandable in the nineties before C++ was standardized but is
>unforgivable in this day and age.

That's a fair criticism. wxWidgets (and I assume Qt, but I know less
about how they decide future directions) would welcome a modern
version of the toolkit that used C++ more directly. However, consider
that wxWidgets is constrained by the underlying GUI toolkit of the
environment (Win32, Cocoa, Tcl/Tk, whatever). There isn't always a
good mapping from modern C++ to these underlying systems.

And jesus, no, we don't need something that isn't an evolution of what
we currently have. In other words, creating an ivory tower type GUI
library that feels good from a modern C++ perspective, but provides no
bridge to existing GUI technologies or API is a complete waste of
time. Existing defacto standards have momentum and pretending that
your library is better without that momentum on your side is silly.
It can't be 10% or even 50% better if you're proposing an entirely new
library, it has to be 5000% better to convince people it's worth
learning/switching from what they already know.

>Development of WinForms has stopped well over a decade ago, [...]

The key thing you're all missing when you list GUI libraries for these
other languages is THEY ARE NOT PART OF THE STANDARD. Sometimes this is
because there is no standard for the language, or because the standard
only specifies the language and not any pile of libraries on top). C#
standard doesn't specify the .NET Framework, which is a pile of libraries
from Microsoft. And so-on.

My point is that these other languages are doing just fine,
thank you, without "standardizing" a GUI toolkit. So is C++.
There is no need for a GUI toolkit in the C++ standard because we
already have defacto standards that are serving the need just fine.
I could understand this clamor for a GUI toolkit if there was nothing
available and there was a huge screaming void, but there have been
C++ GUI toolkit libraries since 1988 when InterViews was described
and that was done straight on top of Xlib, which was a C API.
<http://www.cs.tufts.edu/~nr/cs257/archive/mark-linton/interviews.pdf>
--
"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>

[Richard]

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

Dear brainless piece of wood: fuck off

[David Brown]

Maybe the sister's /real/ psychology trick was training her brother to
believe in that urban legend :-)

[Daniel]

On Tuesday, March 1, 2016 at 1:19:30 AM UTC-5, red floyd wrote:
>
> I thought that was an urban legend. I've seen it many times on
> the net.

My sister's class accomplished this sometime in the late 1970's, in a psychology class at the University of Western Ontario. It was one of the things that students did at the time.

Daniel

[woodb...@gmail.com]

On Tuesday, March 1, 2016 at 12:58:18 AM UTC-6, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Dear

"Therefore I will boast all the more gladly about my
weaknesses, so that Messiah's/Christ's power may rest
on me. That is why, for Messiah's sake, I delight in
weaknesses, in insults, in hardships, in persecutions,
in difficulties. For when I am weak, then I am strong."
2nd Corinthians 12:9-10

[Scott Lurndal]

woodb...@gmail.com writes:
>On Tuesday, March 1, 2016 at 12:58:18 AM UTC-6, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Dear
>
>"Therefore I will boast all the more gladly about my

>weaknesses".


Please, not here.

[Christian Gollwitzer]

Am 01.03.16 um 18:51 schrieb woodb...@gmail.com:

> "Therefore I will boast all the more gladly about my
> weaknesses, so that Messiah's/Christ's power may rest
> on me. That is why, for Messiah's sake, I delight in
> weaknesses, in insults, in hardships, in persecutions,
> in difficulties. For when I am weak, then I am strong."
> 2nd Corinthians 12:9-10

Please do not evangelize here.

Christian (by name)

[Richard]

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

There is no god, there is no messiah. You are suffering from
delusional thinking. Take your religious bigotry and flaming
out of this newsgroup and stop trying to be the world's policeman on
language.

You should have understood by now that the more you attempt to
castigate me, you only come off like a self-righteous dickhead.

If you want to follow the teachings of Jesus, why don't you exercise
a little humility and realize that you are not the master of all
human beings on this planet.

[Dombo]

Op 28-Feb-16 om 23:27 schreef Öö Tiib:

1. Communication; make sure everyone in the team understands the design
and understands what should go where and the rationale behind your
design decisions.

2. Staffing; if there are people on your team that are unable to
understand that business logic should not go into the UI code, or lack
the discipline to keep them separate, fire them. They are gonna cause
problems in other areas as well so you are better of without them.

3. Code reviews; make sure that there is more than one person that has
seen the code before it is committed.

4. Namespaces; keep the UI code in a separate namespace from the
business logic and don't allow the use of "using namespace" with a wide
scope. This makes it obvious were you are in the code and when you are
crossing boundaries without having to write error-prone/no-added-value
glue code.

5. Keep UI and business logic separate by using separate
projects/libraries and/or processes for UI and business logic. Separate
process can be a bit more of a pain (though there several interprocess
communication solutions that alleviate this), but there are other
reasons why you want to have the UI in a separate process, such as
reducing the impact of a bug in the UI code.

> The product gets actually produced quicker that way since UI-less
> application logic is easier to unit test and automatic test and any
> peck or panic about UI features does not accidentally screw
> application logic up. It is not hard to sell such architecture to
> shareholders since there is prospect to put business logic into
> "cloud", UI into "web" or "apps" or whatever the current buzzwords
> are.

No argument here, like I said before I'm all for keeping a clear

separation between UI and business logic.

>> And lets be honest; keeping the UI code separate from business logic is
>> not the reason why those GUI toolkits have their own string and
>> container classes. Just look at Qt, it is (unfortunately) not just a GUI
>> library, but provides classes for just about anything they could think
>> of, including lots of stuff that has absolutely nothing to do with UI.
>> And guess what; those non-UI classes use the same string types and
>> container types as used for the GUI part, apparently Qt didn't thought
>> it was necessary to introduce more incompatible string and container
>> classes to make the distinction between UI and business logic clear.
>
> I agree. There is odd megalomania on case of Qt. Most things that Qt
> incorporates besides GUI are not hard to dump however. Those have
> better alternatives freely available.
>
>> One of the things that separates C++ from other modern programming
>> languages is the inconsistent mess of (naming) conventions, strings,
>> containers...etc you get confronted with if you use multiple libraries
>> from various sources. Not a good thing in my book.
>
> That is very same with other languages as well. Everybody wants to
> have some personal "style". More like samurais than engineers.

I don't see this in Java, I don't see this in C#, and hell even in
Python libraries often smoothly work together. Of all the programming
language I have dealt with the last 20 years (more than I care to
remember) C++ is the worst offender in this area.

[woodb...@gmail.com]

I think there are some benefits to minimizing your libraries:

1. You get more familiar with the libraries you use that way.
2. Smaller executable size and no need for fruitless copies,
e.g. between different string classes.

"There are rules behind the rules and a unity that is
deeper than uniformity." C.S. Lewis

>
> I don't see this in Java, I don't see this in C#,

Please don't swear here.

Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[Dombo]

Op 01-Mar-16 om 7:55 schreef Richard:

> [Please do not mail me a copy of your followup]
>
> Dombo <do...@disposable.invalid> spake the secret code
> <nasqe0$vgd$1...@dont-email.me> thusly:
>
>> Op 27-Feb-16 om 5:19 schreef Alf P. Steinbach:
>>> On 27.02.2016 01:54, Richard wrote:
>>>> Lynn McGuire <l...@winsim.com> spake the secret code
>>>> <naqk3a$s2i$1...@dont-email.me> thusly:
>>>>
>>>>> There is not a standard user interface toolkit proposal.
>>>>
>>>> Don't need it.
>>>>
>>>> There are already several good defacto standards: Qt, wxWidgets, and
>>>> (less to my personal taste, but relevant) MFC. [...]
>>
>> Unfortunately those user interface kits are showing their age; they
>> don't take advantage of modern C++ features but instead choose to supply
>> their own string, container...etc classes and mechanisms. All of this
>> was understandable in the nineties before C++ was standardized but is
>> unforgivable in this day and age.
>
> That's a fair criticism. wxWidgets (and I assume Qt, but I know less
> about how they decide future directions) would welcome a modern
> version of the toolkit that used C++ more directly. However, consider
> that wxWidgets is constrained by the underlying GUI toolkit of the
> environment (Win32, Cocoa, Tcl/Tk, whatever). There isn't always a
> good mapping from modern C++ to these underlying systems.

wxWidgets is clearly inspired by MFC; not my favorite to put it mildly.
In the defense of MFC one can argue that when it was conceived in the
early nineties the Microsoft compiler supported little more than "C with
classes"; no exceptions, no templates, no standard library (thus no
standard string and container classes) and slow processors and a not
terribly clever compiler. No such excuses for wxWidgets.

As far the underlying GUI toolkit and modern C++ features are concerned;
those are mostly orthogonal aspects.

> And jesus, no, we don't need something that isn't an evolution of what
> we currently have. In other words, creating an ivory tower type GUI
> library that feels good from a modern C++ perspective, but provides no
> bridge to existing GUI technologies or API is a complete waste of
> time. Existing defacto standards have momentum and pretending that
> your library is better without that momentum on your side is silly.

The problem in the C++ world is that there is no defacto standard as far
as UI toolkits are concerned, there are god know how many C++ UI
libraries out there. Qt being arguably the best one if you can live with
the bloat, but still far from ideal as far as I'm concerned.

And by the way I don't have my own UI library, and have zero intention
to create one. Those are the kind of things I rather buy than build myself.

>> It can't be 10% or even 50% better if you're proposing an entirely new
>> library, it has to be 5000% better to convince people it's worth
>> learning/switching from what they already know.

You are missing the point. I find building UI applications in C++ rather
unproductive compared to most other programming languages I know of. One
reason is that they don't take advantage of modern C++ features (they
added those to the language for reason you know) but instead rely on on
their own kludges to implement features C++ compliers didn't have back
in the nineties. Another being that C++ UI libraries tend to have their
own types for string and containers. Now I'm not a big fan of the
standard library, but it is a _standard_ supported by all compilers. The
problem with a library having its own types is you have to write glue
code (which is error prone and doesn't add value) unless the library
does every you will ever need, which is probably the reason why Qt
attempts to provide everything but the kitchen sink.

>> Development of WinForms has stopped well over a decade ago, [...]
>
> The key thing you're all missing when you list GUI libraries for these
> other languages is THEY ARE NOT PART OF THE STANDARD. Sometimes this is
> because there is no standard for the language, or because the standard
> only specifies the language and not any pile of libraries on top). C#
> standard doesn't specify the .NET Framework, which is a pile of libraries
> from Microsoft. And so-on.

Strawman argument. I'm not arguing for having a C++ UI library in the
standard. I'm arguing for a UI library that smoothly interfaces with the
types provided by the standard library.

> My point is that these other languages are doing just fine,
> thank you, without "standardizing" a GUI toolkit.

Unlike C++ many programming languages, like C#, have one or only a very
few "defacto" UI libraries that do interface smoothly with the types in
standard library that comes with the language.

> So is C++.

If you just need an UI, C++ is rarely the best option IMO.

> There is no need for a GUI toolkit in the C++ standard because we
> already have defacto standards that are serving the need just fine.

Notice the words "defacto" and "standards" . Now think about that for a
moment (hint: the latter word is plural).

> I could understand this clamor for a GUI toolkit if there was nothing
> available and there was a huge screaming void, but there have been
> C++ GUI toolkit libraries since 1988 when InterViews was described
> and that was done straight on top of Xlib, which was a C API.
> <http://www.cs.tufts.edu/~nr/cs257/archive/mark-linton/interviews.pdf>

Again strawman argument. No one is claiming there are no UI toolkits for
C++, if anything there are rather too many which is an indication that
there are apparently more people not too satisfied with the UI libraries
that already existed.

[Dombo]

Op 06-Mar-16 om 20:59 schreef woodb...@gmail.com:

> On Sunday, March 6, 2016 at 1:10:11 PM UTC-6, Dombo wrote:

>> I don't see this in Java, I don't see this in C#,
>
> Please don't swear here.

Are you a programming language bigot as well?

[woodb...@gmail.com]

I'm free to choose what language(s) I like.
C++ is my favorite. Java sucks IMO.

> as well?

That sort of anti-religious bigotry has worked in
some places, but won't work here.

Brian
Ebenezer Enterprises - "Free at last; free at last.
Thank G-d Almighty we are free at last." ML King Jr.

http://webEbenezer.net

[Öö Tiib]

On Sunday, 6 March 2016 21:10:11 UTC+2, Dombo wrote:
> Op 28-Feb-16 om 23:27 schreef Öö Tiib:
> > On Sunday, 28 February 2016 23:17:31 UTC+2, Dombo wrote:
> >> Op 27-Feb-16 om 20:23 schreef Öö Tiib:
> >>> On Saturday, 27 February 2016 20:41:05 UTC+2, Dombo wrote:
> >>>>
> >>>> It would be nice to have a multi platform widely used GUI toolkit that
> >>>> takes advantage of modern C++ and that smoothly interfaces with the
> >>>> standard library.
> >>>
> >>> I like harshly interfacing GUI. I dislike code where program logic is
> >>> intermixed with GUI and I congratulate GUI toolkit that makes it as
> >>> painful as possible for those who let so different responsibilities
> >>> to diffuse all over the code base.
> >>
> >> I'm all for keeping a clear separation between UI and business logic.
> >> But there are better ways to accomplish that than introducing
> >> incompatible types. Making interfacing with the standard library
> >> unnecessarily hard just stimulates people to just do everything in the
> >> UI code to avoid having to write error-prone/no-added-value glue code to
> >> interface with other parts of the program.
> >
> > What are the better ways? I sometimes suggest separate processes for
> > UI and business logic but that makes interfacing even harsher so I
> > don't think you meant that.
>
> 1. Communication; make sure everyone in the team understands the design
> and understands what should go where and the rationale behind your
> design decisions.

Lot of meetings and workshops and documentation about design
are not so much better than inconvenience of misuse.

>
> 2. Staffing; if there are people on your team that are unable to
> understand that business logic should not go into the UI code, or lack
> the discipline to keep them separate, fire them. They are gonna cause
> problems in other areas as well so you are better of without them.

Staffing is important anyway but too much focus on fear and horror can't
be better than easily observable inconvenience of misuse.

>
> 3. Code reviews; make sure that there is more than one person that has
> seen the code before it is committed.

That is so either way. It is easier to spot diffusion of responsibilities
during review when it was inconvenient and inelegant to write that.

>
> 4. Namespaces; keep the UI code in a separate namespace from the
> business logic and don't allow the use of "using namespace" with a wide
> scope. This makes it obvious were you are in the code and when you are
> crossing boundaries without having to write error-prone/no-added-value
> glue code.

That is so either way but I prefer different namespace by module.
For me quality of the interfacing code between modules adds lot of
value since different modules may be made by different teams and so
the integration is typically expensive step. That "no-added-value
glue code" is on what it depends how fast the issues are sorted out
and blamed correctly. Keeping the interface clear and narrow makes
it harder to diffuse responsibilities to other side of it.

The layer where data from user interface is converted into application
logic data is precisely where "dirty" data becomes "clean" data. Dirty
data from UI is something about that program has to validate carefully
and reject it nicely when invalid because it is produced by clueless,
clumsy and smug humans. However same may happen with whatever other
module (that may be also produced by clueless, clumsy and smug humans).

>
> 5. Keep UI and business logic separate by using separate
> projects/libraries and/or processes for UI and business logic. Separate
> process can be a bit more of a pain (though there several interprocess
> communication solutions that alleviate this), but there are other
> reasons why you want to have the UI in a separate process, such as
> reducing the impact of a bug in the UI code.

Yes but there we have inter-process communication layer that is
inconvenience of transferring the responsibilities by design and does not
interface smoothly with application layer code.

> >
> >> One of the things that separates C++ from other modern programming
> >> languages is the inconsistent mess of (naming) conventions, strings,
> >> containers...etc you get confronted with if you use multiple libraries
> >> from various sources. Not a good thing in my book.
> >
> > That is very same with other languages as well. Everybody wants to
> > have some personal "style". More like samurais than engineers.
>
> I don't see this in Java, I don't see this in C#, and hell even in
> Python libraries often smoothly work together. Of all the programming
> language I have dealt with the last 20 years (more than I care to
> remember) C++ is the worst offender in this area.

Experiences differ. For me worst code that I have ever had to deal with
was a commercial setup tool for specific hardware written in C#. It was
close to worst offender in several areas including lack of consistency of
style whatsoever.

[Richard]

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

Dombo <do...@disposable.invalid> spake the secret code

<nbhv4b$lmu$1...@dont-email.me> thusly:

>Op 28-Feb-16 om 23:27 schreef 嘱 Tiib:

>> On Sunday, 28 February 2016 23:17:31 UTC+2, Dombo wrote:

>>> Op 27-Feb-16 om 20:23 schreef 嘱 Tiib:

>>> One of the things that separates C++ from other modern programming
>>> languages is the inconsistent mess of (naming) conventions, strings,
>>> containers...etc you get confronted with if you use multiple libraries
>>> from various sources. Not a good thing in my book.
>>
>> That is very same with other languages as well. Everybody wants to
>> have some personal "style". More like samurais than engineers.
>
>I don't see this in Java, I don't see this in C#, and hell even in
>Python libraries often smoothly work together. Of all the programming
>language I have dealt with the last 20 years (more than I care to
>remember) C++ is the worst offender in this area.

+1

Sometimes the style differences border on the silly. I once had an
engineer insist that "char* p" was legible but "char *p" was illegible.

If the moving of a single space character prevents you from reading
code, you have no business being a programmer.

My position was that my fingers like to type "char *p" and that our
team should be able to handle either style without difficulty. In
other words, I was reciting "0. Don't sweat the small stuff" from "C++
Coding Standards" by Herb Sutter and Andrei Alexandrescu
<http://amzn.to/1QBURJz>. Apparently obsessing about exceedingly
minor variations in whitespace is what makes code legible. LOL.

[Richard]

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

Dombo <do...@disposable.invalid> spake the secret code

<nbi271$272$1...@dont-email.me> thusly:

>The problem in the C++ world is that there is no defacto standard as far
>as UI toolkits are concerned, there are god know how many C++ UI
>libraries out there. Qt being arguably the best one if you can live with
>the bloat, but still far from ideal as far as I'm concerned.

I disagree that there is no defacto standard. There are two prominent
ones: Qt and wxWidgets. MFC is there as well, but not being cross
platform it never achieved industry wide defacto status. Perhaps
defacto on Windows, though I prefer WTL for Windows only UI
programming.

>You are missing the point. I find building UI applications in C++ rather
>unproductive compared to most other programming languages I know of. One
>reason is that they don't take advantage of modern C++ features (they
>added those to the language for reason you know) but instead rely on on
>their own kludges to implement features C++ compliers didn't have back
>in the nineties.

As someone that works on a Qt application every day and a wxWidgets
application part-time, I disagree. Yes, those things are there if
you want to use them, but nothing is forcing you to use them. I know
in the case of Qt their API is becoming more compatible with STL style
usage in every release.

>Another being that C++ UI libraries tend to have their
>own types for string and containers.

So does LLVM and clang. Are you going to throw them under the bus as
well for this? std::string is a decent class, but if you have
specific string needs that don't match the semantics of std::string,
there is nothing inherently "bad" about making your own string class.
Similarly for containers.

>[...] The

>problem with a library having its own types is you have to write glue
>code (which is error prone and doesn't add value) unless the library
>does every you will ever need, which is probably the reason why Qt
>attempts to provide everything but the kitchen sink.

Qt is like emacs. It has a tendency to want to become the only way
you interact with your computer :-).

I think some of this is historical evolution of the API and once it
has a certain momentum, people are loathe to give that up in favor of
something else that (as you say) does exactly the same thing. The
biggest downside of all of that is the maintenance surface for the Qt
developers, but they seem to get funding for it.

>> The key thing you're all missing when you list GUI libraries for these
>> other languages is THEY ARE NOT PART OF THE STANDARD. Sometimes this is
>> because there is no standard for the language, or because the standard
>> only specifies the language and not any pile of libraries on top). C#
>> standard doesn't specify the .NET Framework, which is a pile of libraries
>> from Microsoft. And so-on.
>
>Strawman argument. I'm not arguing for having a C++ UI library in the
>standard. I'm arguing for a UI library that smoothly interfaces with the
>types provided by the standard library.

Well, that is what *you* are arguing for, but it wasn't the statement
that started this whole thread. Please re-examine the subject line of
this thread. The original poster linked to a blog post listing all
the stuff proposed for the C++17 standard so far and lamented that the
standard didn't have a GUI library. *That* is what I'm responding to.

>> My point is that these other languages are doing just fine,
>> thank you, without "standardizing" a GUI toolkit.
>
>Unlike C++ many programming languages, like C#, have one or only a very
>few "defacto" UI libraries that do interface smoothly with the types in
>standard library that comes with the language.
>
>> So is C++.
>
>If you just need an UI, C++ is rarely the best option IMO.
>
>> There is no need for a GUI toolkit in the C++ standard because we
>> already have defacto standards that are serving the need just fine.
>
>Notice the words "defacto" and "standards" . Now think about that for a
>moment (hint: the latter word is plural).

Yeah, there are 2, maybe 3 if you count MFC. Nothing else has enough
brain share or deployed market share to even count as anything close
to a defacto standard.

>> I could understand this clamor for a GUI toolkit if there was nothing
>> available and there was a huge screaming void, but there have been
>> C++ GUI toolkit libraries since 1988 when InterViews was described
>> and that was done straight on top of Xlib, which was a C API.
>> <http://www.cs.tufts.edu/~nr/cs257/archive/mark-linton/interviews.pdf>
>
>Again strawman argument.

No, not a straw man argument, because I am stating this as a hypothetical
reason for why I would understand the clamor. I know what a straw man
argument is and this isn't one. If anything your response is a straw
man argument, LOL.

>No one is claiming there are no UI toolkits for
>C++,

I never said that they were claiming this. This is where you create
your own straw man argument in response to my explicitly hypothetical
statement.

[Mr Flibble]

On 06/03/2016 19:59, woodb...@gmail.com wrote:
> Please don't swear here.

'This video may contain sexual swearwords, I'm afraid. There are 28
'fucks'. Including that one 29. Ah, fuck it, make it 30.' -- Paul Calf

https://www.youtube.com/watch?v=42UCpOzTbNU

/Flibble