"C++17 Is Now Official"

[Lynn McGuire]

"C++17 Is Now Official"
https://www.phoronix.com/scan.php?page=news_item&px=CPP17-Official

"C++17 introduces a number of new language features, support for UTF-8
character literals, inline variables, fold expressions, and more. On the
C++ standard library side is parallel versions of the STL algorithms, a
file-system library derived from Boost, and other additions."

1,605 pages ! ! !

I would still like to see a standard windowing user interface library.

Lynn

[Richard]

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

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

>1,605 pages ! ! !
>
>I would still like to see a standard windowing user interface library.

...presumably because you want to see another 1500 pages added to the
standard?
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Daniel]

On Wednesday, December 6, 2017 at 6:09:51 PM UTC-5, Lynn McGuire wrote:
>
> I would still like to see a standard windowing user interface library.
>

I'd settle for a date and a decimal class.

Daniel

[Melzzzzz]

That is pretty difficult as if this can be implemented portably.

>
> Lynn


--
press any key to continue or any other to quit...

[Andrey Karpov]

Most interesting innovations introduced in C++17: https://www.viva64.com/en/b/0533/

[Öö Tiib]

Standard windowing user interface would be very helpful for lot of
software. However for majority of software it does not make any
sense. Same is perhaps with several other things like with database
support or with networking support.

I would like standard modules support. Had there been standard way
to incorporate modules into our software then such things could be
easily made as separate standards about separate modules.

[David Brown]

On 07/12/17 07:50, Öö Tiib wrote:
> On Thursday, 7 December 2017 01:09:51 UTC+2, Lynn McGuire wrote:
>> "C++17 Is Now Official"
>> https://www.phoronix.com/scan.php?page=news_item&px=CPP17-Official
>>
>> "C++17 introduces a number of new language features, support for UTF-8
>> character literals, inline variables, fold expressions, and more. On the
>> C++ standard library side is parallel versions of the STL algorithms, a
>> file-system library derived from Boost, and other additions."
>>
>> 1,605 pages ! ! !
>>
>> I would still like to see a standard windowing user interface library.
>
> Standard windowing user interface would be very helpful for lot of
> software. However for majority of software it does not make any
> sense. Same is perhaps with several other things like with database
> support or with networking support.

There can be no way to make a windowing user interface library that
pleases everyone. C++ stretches from massive multi-processing systems
to tiny microcontrollers, and screen usage stretches from multiple
synchronised high-resolution screens in a flight simulator to a e-ink
watch display. The range is too great - a standard solution would be
"one size fits nobody", not "one size fits all".

If something can be done to modernise and standardise common toolkits,
and maybe form a common basis and core, that might be practical.
Instead of every toolkit having its own string class, for example, get
them all to use utf-8 in std::string. Move them from their old
containers to standard C++ containers. And so on.

>
> I would like standard modules support. Had there been standard way
> to incorporate modules into our software then such things could be
> easily made as separate standards about separate modules.
>

Modules would be good. Other things that need finished off and put in
the standard are Concepts and Ranges. Coroutines are another potential
big step (these require a lot more run-time support, but offer a very
different way of structuring code). Then there are other minor but
useful building blocks like the library fundamentals, concurrency and
parallelism TS's.

These are all fundamentals for C++. Something like windowing support
(and networking, filesystems, etc.) are outer layers - these can be made
independently. The standards should concentrate on the fundamental parts.

The real biggie is metaclasses. That is still at the idea and
brain-storming stage - but assuming the key people can get a consistent,
simple yet flexible solution (and it is looking that way), then I hope
the C++ folks put a great deal of emphasis on these.

[Juha Nieminen]

Öö Tiib <oot...@hot.ee> wrote:
> Standard windowing user interface would be very helpful for lot of
> software. However for majority of software it does not make any
> sense. Same is perhaps with several other things like with database
> support or with networking support.

Maybe they should make a *separate* standard for such a system.
A compiler can implement it as a library or not. (If a compiler
does implement it, it should adhere strictly to the standard,
of course.) But keep it separate from the main C++ standard.

[Chris Ahlstrom]

Daniel wrote this copyrighted missive and expects royalties:

> On Wednesday, December 6, 2017 at 6:09:51 PM UTC-5, Lynn McGuire wrote:
>>
>> I would still like to see a standard windowing user interface library.
>>
> I'd settle for a date and a decimal class.

Boost!?

--
Q: Where's the Lone Ranger take his garbage?
A: To the dump, to the dump, to the dump dump dump!

Q: What's the Pink Panther say when he steps on an ant hill?
A: Dead ant, dead ant, dead ant dead ant dead ant...

[Öö Tiib]

On Thursday, 7 December 2017 10:03:51 UTC+2, David Brown wrote:
> On 07/12/17 07:50, Öö Tiib wrote:
> > On Thursday, 7 December 2017 01:09:51 UTC+2, Lynn McGuire wrote:
> >> "C++17 Is Now Official"
> >> https://www.phoronix.com/scan.php?page=news_item&px=CPP17-Official
> >>
> >> "C++17 introduces a number of new language features, support for UTF-8
> >> character literals, inline variables, fold expressions, and more. On the
> >> C++ standard library side is parallel versions of the STL algorithms, a
> >> file-system library derived from Boost, and other additions."
> >>
> >> 1,605 pages ! ! !
> >>
> >> I would still like to see a standard windowing user interface library.
> >
> > Standard windowing user interface would be very helpful for lot of
> > software. However for majority of software it does not make any
> > sense. Same is perhaps with several other things like with database
> > support or with networking support.
>
> There can be no way to make a windowing user interface library that
> pleases everyone. C++ stretches from massive multi-processing systems
> to tiny microcontrollers, and screen usage stretches from multiple
> synchronised high-resolution screens in a flight simulator to a e-ink
> watch display. The range is too great - a standard solution would be
> "one size fits nobody", not "one size fits all".

Advanced modern UI has other output (like sounds) and various user
input (microphones, cameras, mouses, touch panels, keyboards).
UI design typically expects most input gestures to be tied to and
seamlessly accompanied by output animations and sounds to give
immediate feedback to user that input was recognized. So making
standard windowing interface that takes it all into account would
be fun.

> If something can be done to modernise and standardise common toolkits,
> and maybe form a common basis and core, that might be practical.
> Instead of every toolkit having its own string class, for example, get
> them all to use utf-8 in std::string. Move them from their old
> containers to standard C++ containers. And so on.

Everybody would love that but the C++ committee will never start to
push utf-8. Likes of microsoft and qt are too glued to their legacy
and so will reject all sanity.

>
> >
> > I would like standard modules support. Had there been standard way
> > to incorporate modules into our software then such things could be
> > easily made as separate standards about separate modules.
> >
>
> Modules would be good. Other things that need finished off and put in
> the standard are Concepts and Ranges. Coroutines are another potential
> big step (these require a lot more run-time support, but offer a very
> different way of structuring code). Then there are other minor but
> useful building blocks like the library fundamentals, concurrency and
> parallelism TS's.
>
> These are all fundamentals for C++. Something like windowing support
> (and networking, filesystems, etc.) are outer layers - these can be made
> independently. The standards should concentrate on the fundamental parts.
>
> The real biggie is metaclasses. That is still at the idea and
> brain-storming stage - but assuming the key people can get a consistent,
> simple yet flexible solution (and it is looking that way), then I hope
> the C++ folks put a great deal of emphasis on these.

I am not sure of those generics of generics like Concepts and Metaclasses.
These can bring some uniformity but these can also bring unneeded
complexities and preliminary pessimizations.

All my life I have seen creep of unneeded or rarely needed features
into good things. Such features complicate architecture of the thing.
There always will be some corner case of rare corner case in that
rarely needed feature and that constrains the good thing to be
inefficient for everything. ;)

[David Brown]

Yes, but it also makes it even less suitable for being a part of
standard C++.

It would make a lot more sense to have this a separate project, outside
of standard C++. The kinds of things you want here are very different
from what you want in the main standards - you want fast moving projects
that add support for new features in common systems, new hardware, new
fads. You need to support a massive range of features - image types, 3D
systems, fonts, widgets, events, etc. There are several very different
ways of handling things - callbacks, event loops, messaging, etc. Some
people will want small and limited systems, others will want big and
feature-filled systems. So you might want more than one separate
project here - again not something you would want in the C++ standard
library.

Oh, wait - we already have this. QT, wxWidgets, GTK, etc.

>
>> If something can be done to modernise and standardise common toolkits,
>> and maybe form a common basis and core, that might be practical.
>> Instead of every toolkit having its own string class, for example, get
>> them all to use utf-8 in std::string. Move them from their old
>> containers to standard C++ containers. And so on.
>
> Everybody would love that but the C++ committee will never start to
> push utf-8. Likes of microsoft and qt are too glued to their legacy
> and so will reject all sanity.

QT are coming round to UTF-8. But it is not easy to change history -
compatibility with previous versions is important, and changes must be
gradual. (The same applies to MS, I think.)

>
>>
>>>
>>> I would like standard modules support. Had there been standard way
>>> to incorporate modules into our software then such things could be
>>> easily made as separate standards about separate modules.
>>>
>>
>> Modules would be good. Other things that need finished off and put in
>> the standard are Concepts and Ranges. Coroutines are another potential
>> big step (these require a lot more run-time support, but offer a very
>> different way of structuring code). Then there are other minor but
>> useful building blocks like the library fundamentals, concurrency and
>> parallelism TS's.
>>
>> These are all fundamentals for C++. Something like windowing support
>> (and networking, filesystems, etc.) are outer layers - these can be made
>> independently. The standards should concentrate on the fundamental parts.
>>
>> The real biggie is metaclasses. That is still at the idea and
>> brain-storming stage - but assuming the key people can get a consistent,
>> simple yet flexible solution (and it is looking that way), then I hope
>> the C++ folks put a great deal of emphasis on these.
>
> I am not sure of those generics of generics like Concepts and Metaclasses.
> These can bring some uniformity but these can also bring unneeded
> complexities and preliminary pessimizations.

I can't see how either of these might be pessimisations. They will both
greatly simplify the way classes and templates are written. Concepts
don't give you anything more or less than you could write before - it's
just that you no longer have to have so many enable_if's, template
specialisations, and so on in order to say "this class or template has
/this/ functionality". They also let you make templated functions and
classes in a much neater manner.

Metaclasses improve compile-time generation, remove boiler-plate code,
and make it simpler and more reliable to write classes with common
characteristics. They mean that many nice features can be added to C++
as metaclass libraries instead of language changes.

[Jorgen Grahn]

On Wed, 2017-12-06, Lynn McGuire wrote:
> "C++17 Is Now Official"
> https://www.phoronix.com/scan.php?page=news_item&px=CPP17-Official
>
> "C++17 introduces a number of new language features, support for UTF-8
> character literals, inline variables, fold expressions, and more. On the
> C++ standard library side is parallel versions of the STL algorithms, a
> file-system library derived from Boost, and other additions."

Good news!

> 1,605 pages ! ! !
>
> I would still like to see a standard windowing user interface library.

And yet everyone (I think) who responded, only did so to react to your
last comment.

Does someone has anything to say about the /actual/ C++17? What
features will I use the most when I get around to upgrading, in a few
years?

/Jorgen

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

[Ian Collins]

For us it's a bit of dilemma: use the gcc 6.3 based ARM SDK we have been
testing for a couple of months or start again with 7.2 to get C++17...

Just like when C++11 dropped, it'll take a while to find the new bits
that are really useful day to day. Today I tidied up some tool code by
using the return value form emplace_back, so the journey has begun :)

--
Ian.

[David Brown]

There are lots of nice small things:

template auto

class template argument deduction

inline variables (it took me a while to figure out what these are)

initialisers in "if" and "switch" could be useful sometimes, and make
things a little more consistent. And it will put an end to the hideous
(IMHO) C idiom "if (x = nextVal()) ... ".


"if constexpr" is going to make some templates a /lot/ neater. Along
with constexpr lambdas, it also makes compile-time calculation more
flexible (something I like, since my compiler PC is probably 1000 times
faster than the my target processors!).


When I first heard of them, I thought structured bindings would be
great. Now we have multiple return values from functions:

auto squareroot(double a)
{
if (a >= 0) {
return std::make_pair(std::sqrt(a), true);
}
return std::make_pair(0.0, false);
}

auto foo(double x)
{
auto [sq, valid] = squareroot(x);
if (valid) return sq;
return -x;
}

It is all "auto". It is not quite as neat as multiple returns in
Python, but it is not bad.

But after more thought, I don't like that much. I'd rather write:

auto squareroot2(double a)
{
using Ret = struct {double sq; bool valid;};
if (a >= 0) {
return Ret { std::sqrt(a), true };
}
return Ret { 0, false };
}

auto foo2(double x)
{
auto y = squareroot2(x);
if (y.valid) return y.sq;
return -x;
}

It is still nicely "auto" in the caller, but you no longer have to
remember the order of the return values - it is more robust, and clearer
in the code.

Structured bindings can still be useful for pulling apart arrays.



The new attributes might be nice for people writing portable code - my
code is gcc-specific, so I expect to stick to gcc __attribute__ in most
cases.


std::byte is an odd one - it's a good idea, but I think it was wrong to
allow bitwise operations on it.


std::optional is a good idea, that will lead to code that more clearly
shows the intent:

std::optional<double> squareroot3(double a) {
if (a >= 0) {
return std::sqrt(a);
}
return {};
}

auto foo3(double x) {
auto y = squareroot3(x);
return y.value_or(-x);
}

With gcc at least, the std::optional version here is slightly less
efficient than the others, which is a little surprising and
disappointing. It is unlikely to make a big difference in practice.


std::variant will be useful in many ways, I think.

[jacobnavia]

Le 07/12/2017 à 00:09, Lynn McGuire a écrit :
> 1,605 pages ! ! !

This race to featurism and bloat will never stop...

Nobody knows or understands the whole language. There are so many
esoteric features that to master them all several lifes are necessary.

Sorry I have only one, impossible to waste it learning all those 1605 pages.

[Ian Collins]

On 12/08/2017 12:29 PM, jacobnavia wrote:
> Le 07/12/2017 à 00:09, Lynn McGuire a écrit :
>> 1,605 pages ! ! !
>
> This race to featurism and bloat will never stop...

I'm sure that will will be shocked to learn that most C++ programmers
will welcome and use the new features. You are free to carry on keeping
your head in the sand.

--
Ian

[woodb...@gmail.com]

I'm also using the emplace_back that returns a value. Other than
that the only thing I'm using is string_view. I've played with
class template argument deduction, but am not using it at this
time.

I'm not sure if compiler vendors have realized yet that string_view
and some other things need to be backported to their C++ 2011
compilers. Abseil won't cut it.


Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net

[Ian Collins]

I'm sure you realise by now that this will never happen.

--
Ian.

[Daniel]

On Thursday, December 7, 2017 at 5:56:52 AM UTC-5, Chris Ahlstrom wrote:
> Daniel wrote this copyrighted missive and expects royalties:
>

> Boost!?
>
Unfortunately, many projects, especially open source projects, can't use
boost.

Daniel

[Melzzzzz]

You don't have to use all features ;)

--
press any key to continue or any other to quit...

[Melzzzzz]

Hm, is Boost license that restrictive? I saw some open source projects
using Boost.

>
> Daniel

[Daniel]

On Thursday, December 7, 2017 at 10:19:09 PM UTC-5, Melzzzzz wrote:

> On 2017-12-08, Daniel wrote:
>
> Hm, is Boost license that restrictive? I saw some open source projects
> using Boost.
>

It's not the license, boost license is fine (although it's not obvious to me
why they couldn't have just used MIT.)

Most open source C++ projects are utilities that are used in another
application. The main issue from a user's point of view is that if the
utility uses boost, it introduces a dependency in their application that
they may not want. Particularly if they also use boost, but require a
different version. Generally, users of open source utilities shy away from
ones that introduce dependencies on other libraries. There are generally
several to choose from, the competition in free software is fierce.

This consideration doesn't apply as much to open source C++ projects that
are complete applications, but they're in the minority.

Also, from an open source developer's point of view, it's common to set up
travis builds for as many environments as feasible. Having to build a boost
library for each of those environments is painful.

Daniel

[woodb...@gmail.com]

Yeah, I would never use Boost in the open source parts of
my software, but I use it a little in the closed source parts.
In general, I have more freedom in the closed source parts
than in the open source parts.


Brian
Ebenezer Enterprises
http://webEbenezer.net

[Gareth Owen]

Melzzzzz <Melz...@zzzzz.com> writes:

> On 2017-12-07, jacobnavia <ja...@jacob.remcomp.fr> wrote:
>> Le 07/12/2017 à 00:09, Lynn McGuire a écrit :
>>> 1,605 pages ! ! !
>>
>> This race to featurism and bloat will never stop...
>>
>> Nobody knows or understands the whole language. There are so many
>> esoteric features that to master them all several lifes are necessary.
>>
>> Sorry I have only one, impossible to waste it learning all those 1605 pages.
>
> You don't have to use all features ;)

And, indeed, who besides compiler writers and serious language wonks
actually read language standards all the way through? (I'm sure some
people in this group do, but I suspect its a small minority of C++
programmers.)

The rest of us learn by browsing cppreference.com or reading
descriptions of the new features here or otherwise online. We learn new
idioms by example, and dip into the standard only for corner cases.

Just like movie review aggregators, online discussions of the new
features help us see the stuff that other people like or find useful,
and then we can concentrate on learning that.

The length of a language standard is of no more relevance than the
length of a phone book.

[Melzzzzz]

On 2017-12-08, Gareth Owen <gwo...@gmail.com> wrote:
> Melzzzzz <Melz...@zzzzz.com> writes:
>
>> On 2017-12-07, jacobnavia <ja...@jacob.remcomp.fr> wrote:
>>> Le 07/12/2017 à 00:09, Lynn McGuire a écrit :
>>>> 1,605 pages ! ! !
>>>
>>> This race to featurism and bloat will never stop...
>>>
>>> Nobody knows or understands the whole language. There are so many
>>> esoteric features that to master them all several lifes are necessary.
>>>
>>> Sorry I have only one, impossible to waste it learning all those 1605 pages.
>>
>> You don't have to use all features ;)
>
> And, indeed, who besides compiler writers and serious language wonks
> actually read language standards all the way through? (I'm sure some
> people in this group do, but I suspect its a small minority of C++
> programmers.)
>
> The rest of us learn by browsing cppreference.com or reading
> descriptions of the new features here or otherwise online. We learn new
> idioms by example, and dip into the standard only for corner cases.

Heh I learned most reading this group ;p
(and browsing cppreference).

>
> Just like movie review aggregators, online discussions of the new
> features help us see the stuff that other people like or find useful,
> and then we can concentrate on learning that.
>
> The length of a language standard is of no more relevance than the
> length of a phone book.

Yep. Whatever features are there we'll find out if and when we need them
;p

[David Brown]

On 08/12/17 07:22, Gareth Owen wrote:
> Melzzzzz <Melz...@zzzzz.com> writes:
>
>> On 2017-12-07, jacobnavia <ja...@jacob.remcomp.fr> wrote:
>>> Le 07/12/2017 à 00:09, Lynn McGuire a écrit :
>>>> 1,605 pages ! ! !
>>>
>>> This race to featurism and bloat will never stop...
>>>
>>> Nobody knows or understands the whole language. There are so many
>>> esoteric features that to master them all several lifes are necessary.
>>>
>>> Sorry I have only one, impossible to waste it learning all those 1605 pages.
>>
>> You don't have to use all features ;)
>
> And, indeed, who besides compiler writers and serious language wonks
> actually read language standards all the way through? (I'm sure some
> people in this group do, but I suspect its a small minority of C++
> programmers.)

Indeed. I have read most of the C11 standard and know my way around it
quite well now, but C++ standards are a far bigger job. The library
parts in particular are only useful for implementers who need the exact
specifications - they are certainly not learning resources!

>
> The rest of us learn by browsing cppreference.com or reading
> descriptions of the new features here or otherwise online. We learn new
> idioms by example, and dip into the standard only for corner cases.

Yes - www.cppreference.com is a very useful site. And there are lots of
good blogs around for describing the newer features.

[Ian Collins]

On 12/08/2017 07:22 PM, Gareth Owen wrote:
> Melzzzzz <Melz...@zzzzz.com> writes:
>
>> On 2017-12-07, jacobnavia <ja...@jacob.remcomp.fr> wrote:
>>> Le 07/12/2017 à 00:09, Lynn McGuire a écrit :
>>>> 1,605 pages ! ! !
>>>
>>> This race to featurism and bloat will never stop...
>>>
>>> Nobody knows or understands the whole language. There are so many
>>> esoteric features that to master them all several lifes are necessary.
>>>
>>> Sorry I have only one, impossible to waste it learning all those 1605 pages.
>>
>> You don't have to use all features ;)
>
> And, indeed, who besides compiler writers and serious language wonks
> actually read language standards all the way through? (I'm sure some
> people in this group do, but I suspect its a small minority of C++
> programmers.)

Times have certainly changed. I kept hard copies of C99 and C++98 and
used them as a reference on an almost daily basis. I've barely dipped
into C++11 or 14.

> The rest of us learn by browsing cppreference.com or reading
> descriptions of the new features here or otherwise online. We learn new
> idioms by example, and dip into the standard only for corner cases.

As we now do in most things. Where I used to have a shelf of well
thumbed data books, my current hardware colleagues barely have any. The
only things cluttering my desk these days are ever bigger screens and
unopened bills...

--
Ian.

[David Brown]

I still have the bookshelves full, but rarely read them now. But my
desk is still cluttered - it has papers to an average depth of a couple
of inches, hundreds of dead post-it notes, three keyboards, coffee cups,
electronics boards, uncountably many USB sticks. I like to have things
at hand!

[Scott Lurndal]

It will likely be a decade before our toolchain and dependencies
will support moving to a version of GCC that supports C++17.

[red floyd]

On 12/8/2017 12:46 AM, David Brown wrote:
> I still have the bookshelves full, but rarely read them now. But my
> desk is still cluttered - it has papers to an average depth of a couple
> of inches, hundreds of dead post-it notes, three keyboards, coffee cups,
> electronics boards, uncountably many USB sticks. I like to have things
> at hand!

Quit snooping around my office!!!

[Richard]

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

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

>Does someone has anything to say about the /actual/ C++17? What
>features will I use the most when I get around to upgrading, in a few
>years?

I like this summary of the new features:

<https://www.viva64.com/en/b/0533/>

I think the biggest impact is going to be for authors of libraries,
particularly libraries utilizing the technique of expression
templates.

Working from the feature list in the above URL, it's more likely that
these features would impact your day-to-day work:

- *this capture in lambdas
- filesystem
- [[fallthrough]], [[nodiscard]] and [[maybe_unused]] attributes
- structured bindings
- initializer in if/switch
- std::byte type
- std::optional, std::any, std::variant values
- std::string_view
- namespace deeply::nested::name
- std::clamp
- single argument static_assert
- std::shared_ptr for arrays

That list is not exhaustive; it's just my guess of day-to-day impact
from skimming the features.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Ian Collins]

On 12/09/2017 06:08 AM, Scott Lurndal wrote:

> Jorgen Grahn <grahn...@snipabacken.se> writes:
>>
>> Does someone has anything to say about the /actual/ C++17? What
>> features will I use the most when I get around to upgrading, in a few
>> years?
>
> It will likely be a decade before our toolchain and dependencies
> will support moving to a version of GCC that supports C++17.

Why so long? I would have though any changes that improve performance
would be welcomed in your line of work.

--
Ian.

[Richard]

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

Ian Collins <ian-...@hotmail.com> spake the secret code
<f8u1se...@mid.individual.net> thusly:

The irony is that the new features and "bloat" are very much in the same
vein as C++11: they make lots of code simpler and more uniform.

Let's take one feature as an example: constexpr if. You can do the
equivalent thing in C++03, but it requires lots of template boiler plate
and dispatch-by-tag mechanisms. The same code in C++17 is easier to
read, easier to understand and considerably shorter without all the
boiler plate.

Or how about filesystem. It adds a considerable amount of text to the
standard. However, I think most people will find it incredibly useful
in their day-to-day work and ask themselves "why didn't we have this
sooner?". It's another example of how libraries get proven with many
years of real-world experience in Boost before migrating into the
standard.

Oh yeah, now I remember why that guy is in my KILL file :)

[Mr Flibble]

The only people who need to learn all those 1605 pages are people who
contribute to the Standard itself and even then you can probably
specialize and concentrate on a subset.

You don't need to remember all the member functions std::basic_string
has in order to use it effectively as you can always refer to your
favourite reference book or Google it (cppreference.com is great). IDE
auto-complete/intellisense can also be a great help.

/Flibble

[Richard]

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

Ian Collins <ian-...@hotmail.com> spake the secret code

<f904rs...@mid.individual.net> thusly:

Chandler Carruth had a good talk at pacific++ recently on this topic:
<https://www.youtube.com/watch?v=uZI_Qla4pNA>

When I worked at Fusion-io, we targeted enterprise Linux distributions
(RHEL, SLES, etc.) where the default toolchain on the platform lagged
considerably.

At another employer, we were stuck using older tools due to ABI/OS
compatibility concerns. (The application had a plugin architecture
and binary compatibility was susceptible to breakage by changing
toolchains.)

Chandler's point was that for many people it is feasible to build
clang yourself in order to obtain an up-to-date toolchain. On the
Windows side, VS2017 claims ABI compatibility with VS2015, so that
shouldn't be too much of a problem.

[Ian Collins]

Our Windows desktop users are transitioning to VS2017, on the Linux
(Ubuntu) side the llvm project provides clang 5 packages and for those
of us who like life on the edge, daily clang 6 packages. So we have no
issues with C++17 on the desktop.

The embedded tool chain (https://www.yoctoproject.org) is more of an
issue. We have almost finished validating the current release with uses
gcc 6.3. The big question is do we abandon that and go for the next
release which would give us 7.2? An interesting discussion for next week

--
Ian.

[jacobnavia]

Le 08/12/2017 à 19:46, Richard a écrit :
> Oh yeah, now I remember why that guy is in my KILL file:)

Well, apparently you read my posts, so your kill file is not working
properly.

But is representative of the attitude prevailing here.

KILL it.

Asking for simplicity and easy of use, is something C++ guys seem to
take as a personal insult. Any critic is an heresy, a holy wwar is
necessary.

Maybe, I do not think that software discussions should be done at a
personal level. C++ can be criticized, as C can, or any language
whatsoever.

[Scott Lurndal]

It's qualifying all the new software while seven different
projects are using it, making sure the third-party libraries
work with the new toolsets, and for the verification side
of things, most of that software is compiled by the vendor
and distributed as shared objects. Moving to a newer version of the C++
standard isn't sufficient justification for the switch. It will
be driven by external factors, for the most part.

And it's not clear that C++17 would increase performance.

[Ian Collins]

On 12/09/2017 09:16 AM, jacobnavia wrote:
> Le 08/12/2017 à 19:46, Richard a écrit :
>> Oh yeah, now I remember why that guy is in my KILL file:)
>
>
> Well, apparently you read my posts, so your kill file is not working
> properly.

He read the bit I quoted.

> But is representative of the attitude prevailing here.
>
> KILL it.
>
> Asking for simplicity and easy of use, is something C++ guys seem to
> take as a personal insult. Any critic is an heresy, a holy wwar is
> necessary.

We know what drives your vitriolic postings about C++. You have nailed
your colours to the mast of a language that, despite your best efforts,
is unwilling to change. It's not surprising that you resent a language
that embraces change.

> Maybe, I do not think that software discussions should be done at a
> personal level. C++ can be criticized, as C can, or any language
> whatsoever.

Very true, but unfounded criticism will never be well received. Rather
than snipping you should take heed of Richard's main point about C++17:

"The irony is that the new features and "bloat" are very much in the
same vein as C++11: they make lots of code simpler and more uniform."

--
Ian.

[jacobnavia]

Le 08/12/2017 à 21:40, Ian Collins a écrit :
>
>
> Very true, but unfounded criticism will never be well received.  Rather
> than snipping you should take heed of Richard's main point about C++17:
>
> "The irony is that the new features and "bloat" are very much in the
> same vein as C++11: they make lots of code simpler and more uniform."
>

Look, constexpr if, at
https://medium.com/@LoopPerfect/c-17-vs-c-14-if-constexpr-b518982bb1e2

That piece explain us why this improvement to C++ is necessary. You have
code like this in C++ 2014.

template<unsigned n>
struct Arg {
template<class X, class…Xs>
constexpr auto operator()(X x, Xs…xs) {
return Arg<n-1>{}(xs…);
}
};

Not very readable, I agree with the author of that piece. And that is
replaced by:

template<unsigned n>
struct Get {
template<class X, class…Xs>
constexpr auto operator()(X x, Xs…xs) {
if constexpr(n > sizeof…(xs) ) {
return;
} else if constexpr(n > 0) {
return Get<n-1>{}(xs…);
} else {
return x;
}
}
};

in C++ 2017.

The use case is:

// arg<2>(0,1,2,3,4,5) == 2;

OK. You want to access the arguments of a function *by position*. Using
*names* for arguments is much better in my humble opinion, and both the
example and the solution in C++ 2017 can't escape the fact that is much
better to access arguments by their names... if any. In the case of
functions with a variable arguments list, you can (and should) use
default arguments for them, i.e. documented default args readable in the
function declaration.

What strikes me is that the only use case that the author tried to
figure out was a solution to a non-existing need: accessing your
arguments by a hard coded number.

Let's go on to the second case where the improvements should be needed.

C++ 2014:
template<class T>
auto compute(T x) -> decltype( enable_if_t< supportsAPI(T{}), int>{}) {
return x.Method();
}

You have to define the negative method that I do not show here since it
differs by a "!" only, in the condition above.

C++ 2017:
template<class T>
int compute(T x) {
if constexpr( supportsAPI(T{}) ) {
// only gets compiled if the condition is true
return x.Method();
} else {
return 0;
}
}

Yes. Obviously writing:
auto compute(T x) -> decltype( enable_if_t< supportsAPI(T{}), int>{})

is longer than

if constexpr( supportsAPI(T{}) )

Neat. Is that, however, a real need for so many programmers that the
whole language needs to be updated to support a shorter construct?

And what about C?

#if defined(API_3_5_8)

#endif

Yes but simple solutions (used everywhere) need to be updated and
rewritten in the new way...

This is what I mean with "featurism". A new feature of 2014 needs yet
another new feature in 2017 to be usable in a very terse way. And let's
go on adding features that will need more other stuff like this in 2020.

Many people will say here that the examples (the use cases) were badly
choosen. OK, but why can't the author figure out a better use case,

Why those use cases are so difficult to figure out???

Because they are very few, and even then, dangerous. Accessing arguments
by a bare index is an error in software construction, it leads to
illisible programs!

Argument NAMES should be used.

Shouldn't any new addition to C++ be justified by USE CASES???

By a survey of programmers that asked for that specific feature to be added?

If the features added are really needed by the programmers, the people
writing those descriptions wouldn't need to try to find something: it
would be obvvious to anyone that that is needed and why.

That is not the case here, so my thesis that manyt of these changes are
just bloat stands.

jacob

[Richard]

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

Ian Collins <ian-...@hotmail.com> spake the secret code

<f90bl1...@mid.individual.net> thusly:

>On 12/09/2017 09:16 AM, jacobnavia wrote:
>> Le 08/12/2017 à 19:46, Richard a écrit :
>>> Oh yeah, now I remember why that guy is in my KILL file:)
>>
>>
>> Well, apparently you read my posts, so your kill file is not working
>> properly.
>
>He read the bit I quoted.

Yep. My personal KILL file is for spammers, trolls, troll feeders, or
people for whom I've read enough of their posts to conclude that I'm
unlikely to learn anything from future content based on past content.

I don't record the reason why anyone ends up there, but for this
newsgroup it's probably like 90% are due to troll related postings.

[jacobnavia]

Le 08/12/2017 à 19:56, Mr Flibble a écrit :
> he only people who need to learn all those 1605 pages are people who
> contribute to the Standard itself and even then you can probably
> specialize and concentrate on a subset.

I can't concentrate in a subset since I earn money by maintining C++
software. Yes, maintainers exist, and they have to get the common subset
used by whoever wrote the stuff. Luckily for me, I learn the subsets
used by the authors (or ask them), and then I forget them as soon as I
can when the job is done, to make place for whatever new subset I will find.

Well, luckily for me, most C++ software is written by people that use
0.1% of C++. Still, following unknown code is a nightmare.

[jacobnavia]

Le 08/12/2017 à 22:20, Richard a écrit :
> [Please do not mail me a copy of your followup]
>
> Ian Collins <ian-...@hotmail.com> spake the secret code
> <f90bl1...@mid.individual.net> thusly:
>
>> On 12/09/2017 09:16 AM, jacobnavia wrote:

>>> Le 08/12/2017 à 19:46, Richard a écrit :

>>>> Oh yeah, now I remember why that guy is in my KILL file:)
>>>
>>>
>>> Well, apparently you read my posts, so your kill file is not working
>>> properly.
>>
>> He read the bit I quoted.
>
> Yep. My personal KILL file is for spammers, trolls, troll feeders, or
> people for whom I've read enough of their posts to conclude that I'm
> unlikely to learn anything from future content based on past content.
>

I note that you didn't even start answering anything I said about your
famous "constexpr if". You did not say anything because you have
absolutely no arguments, and I do not remember you arguing anything with
arguments. Just this kind of prose:

> I don't record the reason why anyone ends up there, but for this
> newsgroup it's probably like 90% are due to troll related postings.
>

So, you do not say anything, you support the party line, and all the
people that disagree with his majesty are just trolls, spammers, and the
whole list of insults you vomit at each post.

Note that I do not have kill files, I do not need them. Nobody can
insult me if I do not give any importance to what they are writing or
saying.

[Ian Collins]

On 12/09/2017 10:16 AM, jacobnavia wrote:
>
> Look, constexpr if, at
> https://medium.com/@LoopPerfect/c-17-vs-c-14-if-constexpr-b518982bb1e2
>
> That piece explain us why this improvement to C++ is necessary. You have
> code like this in C++ 2014.
>
> template<unsigned n>
> struct Arg {
> template<class X, class…Xs>
> constexpr auto operator()(X x, Xs…xs) {
> return Arg<n-1>{}(xs…);
> }
> };
>
> Not very readable, I agree with the author of that piece. And that is
> replaced by:
>
> template<unsigned n>
> struct Get {
> template<class X, class…Xs>
> constexpr auto operator()(X x, Xs…xs) {
> if constexpr(n > sizeof…(xs) ) {
> return;
> } else if constexpr(n > 0) {
> return Get<n-1>{}(xs…);
> } else {
> return x;
> }
> }
> };
>
> in C++ 2017.

The example here: https://www.viva64.com/en/b/0533/#ID0EELAK

presents, in my opinion, a more practical example if day to day code.

template <typename T>
auto GetValue(T t)
{
if constexpr (std::is_pointer<T>::value)
{
return *t;
}
else
{
return t;
}
}

I have had to use convoluted SFINAE style code to get a similar effect.
I'll be updating that code next time I visit it.

constexpr if is one of apparently innocuous changes that will prove very
useful once you hit a situation where it saves code - especially where
it moves code from run to compile time.

--
Ian.

[bartc]

On 08/12/2017 18:41, Richard wrote:


> I like this summary of the new features:
>
> <https://www.viva64.com/en/b/0533/>

> - std::byte type

Finally, a C++17 feature (in fact a C++ feature) I can understand.

Yes, this is just a byte type, that doesn't do anything clever. Why did
it take so long to figure out that it was needed?

--
bartc

[Mr Flibble]

I suspect most people will do a "using std::byte;" in their headers.

/Flibble

--
"Suppose it’s all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I’d say, bone cancer in children? What’s that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It’s not right, it’s utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That’s what I would say."

[Robert Wessel]

Honestly, I would have expected that you would have disliked std::byte
because it's not an arithmetic type.

[bartc]

I was trying to find one thing in C++ I couldn't criticise or dislike!

But yes it does have some odd restrictions, which would have been better
applied to char itself (you can multiply a char value by 3, but you
can't do what with a byte).


--
bartc

[Richard]

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

bartc <b...@freeuk.com> spake the secret code
<q%FWB.198368$pG.1...@fx18.am4> thusly:

You seem to be unfamiliar with how the standardization process works.

For everything in the standard, someone has to propose it, defend the
proposal and shepherd the proposal through the entire process. Yes,
this includes even something as simple as std::byte. If noone does
this work, it doesn't end up in the standard despite whatever you may
perceive as the "need" for it.

[Öö Tiib]

On Friday, 8 December 2017 23:22:25 UTC+2, jacobnavia wrote:
> Le 08/12/2017 à 19:56, Mr Flibble a écrit :
> > he only people who need to learn all those 1605 pages are people who
> > contribute to the Standard itself and even then you can probably
> > specialize and concentrate on a subset.
>
> I can't concentrate in a subset since I earn money by maintining C++
> software. Yes, maintainers exist, and they have to get the common subset
> used by whoever wrote the stuff. Luckily for me, I learn the subsets
> used by the authors (or ask them), and then I forget them as soon as I
> can when the job is done, to make place for whatever new subset I will find.

Lot of software development is actually maintenance. Do you really
maintain different software each few months? Why? It sounds very
unusual maintenance. Most maintenance that I know of releases a new
patch every few months and so it goes on for decades.

> Well, luckily for me, most C++ software is written by people that use
> 0.1% of C++. Still, following unknown code is a nightmare.

A person sits behind computer, drinks some warm beverages and solves
there some puzzle. Is the puzzle "boring", "tiresome", "interesting",
"challenging", "problematic", "painful" or outright "nightmare"?
On what that depends?

[David Brown]

On 11/12/17 05:16, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> bartc <b...@freeuk.com> spake the secret code
> <q%FWB.198368$pG.1...@fx18.am4> thusly:
>
>> On 08/12/2017 18:41, Richard wrote:
>>
>>
>>> I like this summary of the new features:
>>>
>>> <https://www.viva64.com/en/b/0533/>
>>
>>> - std::byte type
>>
>> Finally, a C++17 feature (in fact a C++ feature) I can understand.
>>
>> Yes, this is just a byte type, that doesn't do anything clever. Why did
>> it take so long to figure out that it was needed?
>
> You seem to be unfamiliar with how the standardization process works.
>
> For everything in the standard, someone has to propose it, defend the
> proposal and shepherd the proposal through the entire process. Yes,
> this includes even something as simple as std::byte. If noone does
> this work, it doesn't end up in the standard despite whatever you may
> perceive as the "need" for it.
>

Plus, std::byte was /not/ needed. It is helpful, perhaps, and could
make code clearer and reduce the risk of mistakes since you cannot use
arithmetic on std::byte (as you can on "char", "unsigned char" or
"uint8_t" - the popular alternatives). But std::byte can't do anything
you could not already do with "unsigned char" - indeed, it is the /lack/
of features in std::byte that is its strength. Personally, I don't
think the bitwise operators should have been allowed either.

[jacobnavia]

Le 11/12/2017 à 07:52, Öö Tiib a écrit :
>
> A person sits behind computer, drinks some warm beverages and solves
> there some puzzle. Is the puzzle "boring", "tiresome", "interesting",
> "challenging", "problematic", "painful" or outright "nightmare"?
> On what that depends?
>

Is the patch going to break something else somewhere else?

What are the consequences of the patch?

C++ is highly interconnected. Class hierarchy, template instatiations,
all the features that allow highly abstract code make any change a very
perilous exercise unless you master the whole.

SFINAE is fine if you want to avoid template errors with types that
shouldn't be used for this particular template. OK, but now, instead of
an error you get nothing, just your template doesn't apply and you do
not know why or which template did not work. The error (if it is an
error of course) appears somewhere else, in an unrelated part of the
code and you have to figure it out.

Each addition offers new, interesting possibilities of course. The
downside is a higher level of abstraction and distance from the error
symptoms and the source of it.

[woodb...@gmail.com]

On Thursday, December 7, 2017 at 7:39:35 PM UTC-6, Ian Collins wrote:
> On 12/08/2017 02:02 PM, woodb...@gmail.com wrote:
> >
> > I'm also using the emplace_back that returns a value. Other than
> > that the only thing I'm using is string_view. I've played with
> > class template argument deduction, but am not using it at this
> > time.
> >
> > I'm not sure if compiler vendors have realized yet that string_view
> > and some other things need to be backported to their C++ 2011
> > compilers. Abseil won't cut it.
>
> I'm sure you realise by now that this will never happen.
>

Here are some features I think will be back-ported
to C++ 2011 compilers:

1. make_unique
2. string_view
3. emplace_back that returns a value
4. static_assert where the text message is optional

They are easy to back-port. =]

Brian
Ebenezer Enterprises
https://github.com/Ebenezer-group/onwards

[Ian Collins]

There is no point, compilers have moved on.

--
Ian.

[Thiago Adams]

C++ is all about code generation. Any language
is, the difference is that C++ gives some tools
to the programmer to control, customize and
parameterize the generation.


if constexpr, as you said, will reduce the number
of lines and works as a complement of templates.
On limitation of if constexpr is that we
cannot use to select struct data members for
instance.


The code generation family of tools in C++ still
not complete. I can give many samples.

For instance, if C++ had no automatic generated
destructor we would not be able to generate it
using templates. We cannot create a function that
returns the name of one enum item.

Basically the missing part is compile time
reflection + some language to generate code.
"Sutter Metaclasses". The language to describe
the code generation can be imperative or
more declarative. constexpr functions uses
the same language "C++" to generate values but
it cannot generate types.


If C++ had a successful language to do code
generation, templates and if constexpr
would become specialized case that also
could be generated by this more general
language.

I am very interested in this subject of code
generation, and this have some relation with
the code generator I do called cprime.

I think the design of this "language" to
generated code needs to be created and
evolve from use.

I also think that c++ templates are in many ways
are very successful.

[woodb...@gmail.com]

I think on-line code generation is the way things
are headed. One example is https://www.protlr.com/
. Another is the C++ Middleware Writer (CMW).

One strength of Protlr is it generates code that
can be used with Wireshark. A weakness of Protlr
(from what I can tell) is it has a web interface.
The CMW has a command line interface to simplify
integration into build processes.

G-d willing, we'll add support for Wireshark to the CMW
in the future.


Brian
Ebenezer Enterprises
http://webEbenezer.net

[Thiago Adams]

I hope to explain were external generators
doesn't work so well.

Take C++ vector. You can create a template vector
class.
Then you can instantiate the vector<int> v and
instantiate v.push_back.
When you call v.push_back in your code the function
push_back is instantiated. If you remove the line where you call
push_back the function instantiation is removed. Everything
is synchronized and The generated code depends on the code
you write.


Take an enum. You want to create a function to convert
from enum value to text.

enum E {A, B};

const char* ToString(E e) {
switch (e)
{
case A: return "A";
case B: return "B";
}
return "";
}

If you have an external online generator you need
to copy and paste your enum definition.

If code generation as part of the language you don't
need to do this process manually every time you
change the enum.

The second advantage with an "code generator" integrated
with the language is that your code is portable and
someone with the compiler can compile you code without
download more tools and the language is know by
programmers. (Don't need to learn each DSL language in
the world).

External code generators works if you don't need
to change the "source" too much and don't need to synchronize
too much and you must be happy with the generated code without
changes. Some of these problems also happens with parser
generators.

[Mr Flibble]

What could be the possible motivation to back-port to earlier versions
of product? What is the business case? Even more basically, what is the
necessity? "Being easy to do" is not a good enough reason. Just use the
latest version of the compiler if you want the latest version of the
language.

[woodb...@gmail.com]

If the front-end of the on-line generator is web based,
you probably have to copy/paste. I started off with a
web based front-end, but switched to a command line
interface so you don't have to copy/paste anything.

[woodb...@gmail.com]

On Monday, January 15, 2018 at 11:28:36 AM UTC-6, Mr Flibble wrote:
> On 15/01/2018 04:54, woodb...@gmail.com wrote:
> >
> > Here are some features I think will be back-ported
> > to C++ 2011 compilers:
> >
> > 1. make_unique
> > 2. string_view
> > 3. emplace_back that returns a value
> > 4. static_assert where the text message is optional
> >
> > They are easy to back-port. =]
> >
> > Brian
> > Ebenezer Enterprises
> > https://github.com/Ebenezer-group/onwards
> >
>
> What could be the possible motivation to back-port to earlier versions
> of product? What is the business case? Even more basically, what is the
> necessity? "Being easy to do" is not a good enough reason. Just use the
> latest version of the compiler if you want the latest version of the
> language.
>

I have the luxury of using new compilers in some of my work,
but not everyone is as blessed. For a number of reasons that
have been discussed previously in other threads, people are
stuck with older compilers.

C++ 2011 was both late and immature when it did arrive. Better
late than never, but things were a mess. The back-porting is to
finally get C++ 2011 right.

[Ian Collins]

On 01/16/2018 07:16 AM, woodb...@gmail.com wrote:
> On Monday, January 15, 2018 at 11:28:36 AM UTC-6, Mr Flibble wrote:
>> On 15/01/2018 04:54, woodb...@gmail.com wrote:
>>>
>>> Here are some features I think will be back-ported
>>> to C++ 2011 compilers:
>>>
>>> 1. make_unique
>>> 2. string_view
>>> 3. emplace_back that returns a value
>>> 4. static_assert where the text message is optional
>>>
>>> They are easy to back-port. =]
>>

>> What could be the possible motivation to back-port to earlier versions
>> of product? What is the business case? Even more basically, what is the
>> necessity? "Being easy to do" is not a good enough reason. Just use the
>> latest version of the compiler if you want the latest version of the
>> language.
>>
>
> I have the luxury of using new compilers in some of my work,
> but not everyone is as blessed. For a number of reasons that
> have been discussed previously in other threads, people are
> stuck with older compilers.

Quite. Back-porting to a compiler would change the compiler, so anyone
stuck on an older version would remain stuck. The version with back
ported bits would be a different compiler version requiring the same
qualification as a new compiler.

--
Ian.

[woodb...@gmail.com]

True, but 3 of the 4 items I listed are library only. The other
one is a simplification of a C++ 2011 feature. So in these cases,
I don't think what you are saying matters that much.


Brian
Ebenezer Enterprises - "I have a dream that my four little children
will one day live in a nation where they will not be judged by the
color of their skin, but by the content of their character."
Martin Luther King, Jr.

http://webEbenezer.net

[Mr Flibble]

On 15/01/2018 19:13, woodb...@gmail.com wrote:
> On Monday, January 15, 2018 at 1:02:28 PM UTC-6, Ian Collins wrote:
>> On 01/16/2018 07:16 AM, woodb...@gmail.com wrote:
>>>
>>> I have the luxury of using new compilers in some of my work,
>>> but not everyone is as blessed. For a number of reasons that
>>> have been discussed previously in other threads, people are
>>> stuck with older compilers.
>>
>> Quite. Back-porting to a compiler would change the compiler, so anyone
>> stuck on an older version would remain stuck. The version with back
>> ported bits would be a different compiler version requiring the same
>> qualification as a new compiler.
>>
>
> True, but 3 of the 4 items I listed are library only. The other
> one is a simplification of a C++ 2011 feature. So in these cases,
> I don't think what you are saying matters that much.

There are three options:

1) your compiler costs money in which case the company that makes it
needs a business case to forgo profit;
2) your compiler is free in which case download the latest version;
3) you are genuinely stuck with an old compiler for technical reasons in
which case you are genuinely stuck with an old compiler for technical
reasons.

[Scott Lurndal]

woodb...@gmail.com writes:
>On Monday, January 15, 2018 at 1:02:28 PM UTC-6, Ian Collins wrote:
>> On 01/16/2018 07:16 AM, woodb...@gmail.com wrote:
>> >
>> > I have the luxury of using new compilers in some of my work,
>> > but not everyone is as blessed. For a number of reasons that
>> > have been discussed previously in other threads, people are
>> > stuck with older compilers.
>>
>> Quite. Back-porting to a compiler would change the compiler, so anyone
>> stuck on an older version would remain stuck. The version with back
>> ported bits would be a different compiler version requiring the same
>> qualification as a new compiler.
>>
>
>True, but 3 of the 4 items I listed are library only. The other
>one is a simplification of a C++ 2011 feature. So in these cases,
>I don't think what you are saying matters that much.

Doesn't matter what you think. As Ian noted, any change in the
compilation environment (headers, libraries, compilers, etc) requires
significant validation prior to rolling out for production, which
costs time and money.

[Öö Tiib]

That is all time and money of compiler vendors and compiler users.
Brian does not consider that since it is not his time and money. He
just wants only few new features but also wants those to compile on
C++11 compiler. He needs miracle.

[Vir Campestris]

On 15/01/2018 20:22, Mr Flibble wrote:
>
> There are three options:
>
> 1) your compiler costs money in which case the company that makes it
> needs a business case to forgo profit;
> 2) your compiler is free in which case download the latest version;
> 3) you are genuinely stuck with an old compiler for technical reasons in
> which case you are genuinely stuck with an old compiler for technical
> reasons.

There are 4 options -
4) Some of the code base won't build on the new compiler (IME this is
usually because of bugs, and it's worth fixing them)

... OK, among the options are
5) Parts of the company are scared to change the compiler in case it
destabilises things

They don't have to be good reasons.

Andy
--
Nobody expects the Spanish Inquisition!

[Mr Flibble]

Also what you would end up with is a bastardized version of C++ that
bears no relation to an official incarnation of C++ but I guess we kind
of always have that situation anyway due to compiler vendors being slow
on the uptake of new language features implementing some not all (hello
Microsoft).

[Thiago Adams]

On Monday, January 15, 2018 at 4:16:44 PM UTC-2, woodb...@gmail.com wrote:
> On Monday, January 15, 2018 at 11:28:36 AM UTC-6, Mr Flibble wrote:

> > On 15/01/2018 04:54, wrote:
> > >
> > > Here are some features I think will be back-ported
> > > to C++ 2011 compilers:
> > >
> > > 1. make_unique
> > > 2. string_view
> > > 3. emplace_back that returns a value
> > > 4. static_assert where the text message is optional
> > >
> > > They are easy to back-port. =]
> > >
> > > Brian
> > > Ebenezer Enterprises
> > > https://github.com/Ebenezer-group/onwards
> > >
> >
> > What could be the possible motivation to back-port to earlier versions
> > of product? What is the business case? Even more basically, what is the
> > necessity? "Being easy to do" is not a good enough reason. Just use the
> > latest version of the compiler if you want the latest version of the
> > language.
> >
>
> I have the luxury of using new compilers in some of my work,
> but not everyone is as blessed. For a number of reasons that
> have been discussed previously in other threads, people are
> stuck with older compilers.
>
> C++ 2011 was both late and immature when it did arrive. Better
> late than never, but things were a mess. The back-porting is to
> finally get C++ 2011 right.
>
>

What is the motivation to use the latest version
of C++ in the generated code?
You have an external generator, then I presume the
user will not change the generated code. If he does,
then he lost the changes he did. It is one way generation,
is that right?
In this case, the programmer doesn't care about
the code because he don't need to see/change.
In this case C89 has advantages, unless you
have some customization points using templates or
other C++ feature.
C is a very good target for generators.

[cda...@gmail.com]

On Wednesday, December 6, 2017 at 3:09:51 PM UTC-8, Lynn McGuire wrote:
> "C++17 Is Now Official"
> https://www.phoronix.com/scan.php?page=news_item&px=CPP17-Official
>
> "C++17 introduces a number of new language features, support for UTF-8
> character literals, inline variables, fold expressions, and more. On the
> C++ standard library side is parallel versions of the STL algorithms, a
> file-system library derived from Boost, and other additions."
>
> 1,605 pages ! ! !
>
> I would still like to see a standard windowing user interface library.
>

Wasn't this attempted on *nix a few decades ago?

[James Kuyper]

On 01/15/2018 04:54 PM, Vir Campestris wrote:
> On 15/01/2018 20:22, Mr Flibble wrote:

...

>> 3) you are genuinely stuck with an old compiler for technical reasons in
>> which case you are genuinely stuck with an old compiler for technical
>> reasons.
>
> There are 4 options -
> 4) Some of the code base won't build on the new compiler (IME this is
> usually because of bugs, and it's worth fixing them)

That's covered by item 3.

[Vir Campestris]

On 16/01/2018 13:52, James Kuyper wrote:
> On 01/15/2018 04:54 PM, Vir Campestris wrote:
>> On 15/01/2018 20:22, Mr Flibble wrote:

> ....

>>> 3) you are genuinely stuck with an old compiler for technical reasons in
>>> which case you are genuinely stuck with an old compiler for technical
>>> reasons.
>>
>> There are 4 options -
>> 4) Some of the code base won't build on the new compiler (IME this is
>> usually because of bugs, and it's worth fixing them)
>
> That's covered by item 3.
>

OK. I was thinking in terms of no chip support for the new one.

Andy

[Lynn McGuire]

And X-Windows failed to make it outside of Unix (that I know of).

Lynn

[Scott Lurndal]

But still in wide use by linux and bsd unix systems, underlying
all modern toolkits (gtk, qt, Xaw, et alia). Attempts to replace
it (e.g. Wayland) haven't yet succeeded, thankfully.

[Daniel]

On Wednesday, December 6, 2017 at 6:09:51 PM UTC-5, Lynn McGuire wrote:
>
> I would still like to see a standard windowing user interface library.
>

What would they standardize? User interfaces are moving on. Old style
desktop interfaces aren't that interesting anymore.

My wishes are more modest: a standard date and a standard decimal class.
At least for these there is prior work.

Daniel

[Richard]

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

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

It was succesful in that it conquered all the unixes, which was no
small feat. It crushed every vendor specific windowing system, of
which there were quite a few in the late 80s/early 90s. Even SGI had
to relent eventually and they were a powerful force in the workstation
market and in graphics.

As far as the cross-platform API wars, wxWidgets and Qt are the clear
winners. They have different enough approaches that they still
survive to this day (Qt reimplements everything from first principles
and wxWidgets acts more as a minimal adapter layer to give a common
API).

This is exactly why these things are not needed in the standard. I
need to write a paper to the committee.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Lynn McGuire]

Are the Android systems running X-Windows ?

Lynn

[Scott Lurndal]

legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]

>>>

>>> Wasn't this attempted on *nix a few decades ago?
>>
>>And X-Windows failed to make it outside of Unix (that I know of).
>
>It was succesful in that it conquered all the unixes, which was no
>small feat. It crushed every vendor specific windowing system, of
>which there were quite a few in the late 80s/early 90s. Even SGI had
>to relent eventually and they were a powerful force in the workstation
>market and in graphics.

Sort of, GL still exists as OpenGL.

[Richard]

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

Lynn McGuire <lynnmc...@gmail.com> spake the secret code

<p3m19m$mb3$1...@dont-email.me> thusly:

>Are the Android systems running X-Windows ?

(Nit: Technically the name is the "X Window System"
<https://en.wikipedia.org/wiki/X_Window_System>)

Android is a linux kernel with a GUI layer that was originally only
accessible from Java. (Disclaimer: I have a rudimentary understanding
of Android development and haven't done anything with real code.)
This blog post from 2012 shows some layers in their architecture:
<https://www.imgtec.com/blog/learning-about-the-android-graphics-subsystem/>
It is unclear which of these layers are accessible from C++; although
I imagine that all of the are accessible from Java as native
programming came later to Android.

This page seems more current and describes two APIs: Canvas and OpenGL
ES. <https://source.android.com/devices/graphics/> However, that
just covers output, it doesn't cover input or things like common GUI
controls.
<https://source.android.com/devices/input/>

If you look at their UI overview, it's all talking in terms of Java
<https://developer.android.com/guide/topics/ui/overview.html>

The Native Development Kit (NDK) is what you can write in C++:
<https://developer.android.com/ndk/guides/index.html>

Looking here, it looks you still have to do some portion of the UI in
Java if your application wants to use the standard widgets. If your
app is full-screen (e.g. a game) and does everything in OpenGL, then
you can forego the Java portion.
<https://developer.android.com/ndk/guides/stable_apis.html>

[Ian Collins]

XQuartz on Mac.

https://www.xquartz.org/

--
Ian.

[Richard]

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

Ian Collins <ian-...@hotmail.com> spake the secret code
<fc7or9...@mid.individual.net> thusly:

There were also X Window System servers for the PC and X Terminals.
Heck, there is an X Server application in the android store :)

[Lynn McGuire]

Gotcha. It has been almost 30 years since I wrote a modicum of X
Windows code. And some XView code when we got a Sun workstation. Both
were related to an AutoCAD add-on that we were developing.

Lynn

[Alf P. Steinbach]

Second that.


Cheers!,

- Alf

[Fred.Zwarts]

"Ian Collins" schreef in bericht news:fc7or9...@mid.individual.net...

>
>On 01/17/2018 10:23 AM, Lynn McGuire wrote:
>> On 1/16/2018 7:30 AM, cda...@gmail.com wrote:

...

>>
>> And X-Windows failed to make it outside of Unix (that I know of).
>
>XQuartz on Mac.
>
>https://www.xquartz.org/
>

OpenVMS, once a popular OS, started with its own windowing system, but later
moved to X-Windows.

[Scott Lurndal]

legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>
>Ian Collins <ian-...@hotmail.com> spake the secret code
><fc7or9...@mid.individual.net> thusly:
>
>>On 01/17/2018 10:23 AM, Lynn McGuire wrote:
>>> On 1/16/2018 7:30 AM, cda...@gmail.com wrote:
>>>> On Wednesday, December 6, 2017 at 3:09:51 PM UTC-8, Lynn McGuire wrote:
>>>>> "C++17 Is Now Official"
>>>>> https://www.phoronix.com/scan.php?page=news_item&px=CPP17-Official
>>>>>
>>>>> "C++17 introduces a number of new language features, support for UTF-8
>>>>> character literals, inline variables, fold expressions, and more. On the
>>>>> C++ standard library side is parallel versions of the STL algorithms, a
>>>>> file-system library derived from Boost, and other additions."
>>>>>
>>>>> 1,605 pages ! ! !
>>>>>
>>>>> I would still like to see a standard windowing user interface library.
>>>>>
>>>>
>>>> Wasn't this attempted on *nix a few decades ago?
>>>
>>> And X-Windows failed to make it outside of Unix (that I know of).
>>
>>XQuartz on Mac.
>>
>>https://www.xquartz.org/
>
>There were also X Window System servers for the PC and X Terminals.
>Heck, there is an X Server application in the android store :)

There's an x-server and full set of x clients in cygwin, as well.

[woodb...@gmail.com]

On Tuesday, January 16, 2018 at 5:22:01 AM UTC-6, Thiago Adams wrote:
> On Monday, January 15, 2018 at 4:16:44 PM UTC-2, woodb...@gmail.com wrote:
> >
> > I have the luxury of using new compilers in some of my work,
> > but not everyone is as blessed. For a number of reasons that
> > have been discussed previously in other threads, people are
> > stuck with older compilers.
> >
> > C++ 2011 was both late and immature when it did arrive. Better
> > late than never, but things were a mess. The back-porting is to
> > finally get C++ 2011 right.
> >
>
> What is the motivation to use the latest version
> of C++ in the generated code?

3 or the 4 things I mentioned aren't part of the
generated code. I use them in code that supports
the generated code:
https://github.com/Ebenezer-group/onwards

The one that can be part of the generated code is
string_view. String_view is an important addition to
the language in my opinion. From a technical perspective
we could have had it in 2007 rather than 2017.

> You have an external generator, then I presume the
> user will not change the generated code. If he does,
> then he lost the changes he did. It is one way generation,
> is that right?

I'm not sure I understand you, but changes made by a person
to a generated file (For example: https://github.com/Ebenezer-group/onwards/blob/master/tiers/zz.middleBack.hh)

are lost the next time the file is regenerated.

> In this case, the programmer doesn't care about
> the code because he don't need to see/change.
> In this case C89 has advantages, unless you
> have some customization points using templates or
> other C++ feature.
> C is a very good target for generators.

C is more stable than C++, but that's one of the
few things I think it has going for it compared to
C++.


Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net

[Richard]

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

"Fred.Zwarts" <F.Zw...@KVI.nl> spake the secret code
<p3n0lv$1krc$1...@gioia.aioe.org> thusly:

>OpenVMS, once a popular OS, started with its own windowing system, but later
>moved to X-Windows.

Off the top of my head companies/proprietary window systems killed off
by the X Window System:

Sun's SunView
Sun's NeWS
SGI's 4Sight
SGI's MEX
DEC (DECwindows was their name for their X Window System
implementation, IIRC); I think you're right that they had a
proprietary thing before but I don't know what that was called.
Hewlett-Packard
Domain/OS from Apollo had something, I can't remember what it was called.
It might not have had a distinct name for the GUI part.
...and of course there are many smaller manufacturers that had their
own thing.

It's really quite successful that X managed to kill off all these
proprietary islands of functionality and unify them into a single
environment, both for users and developers.

[Lynn McGuire]

On 1/17/2018 8:27 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> "Fred.Zwarts" <F.Zw...@KVI.nl> spake the secret code
> <p3n0lv$1krc$1...@gioia.aioe.org> thusly:
>
>> OpenVMS, once a popular OS, started with its own windowing system, but later
>> moved to X-Windows.
>
> Off the top of my head companies/proprietary window systems killed off
> by the X Window System:
>
> Sun's SunView
> Sun's NeWS
> SGI's 4Sight
> SGI's MEX
> DEC (DECwindows was their name for their X Window System
> implementation, IIRC); I think you're right that they had a
> proprietary thing before but I don't know what that was called.
> Hewlett-Packard
> Domain/OS from Apollo had something, I can't remember what it was called.
> It might not have had a distinct name for the GUI part.
> ...and of course there are many smaller manufacturers that had their
> own thing.
>
> It's really quite successful that X managed to kill off all these
> proprietary islands of functionality and unify them into a single
> environment, both for users and developers.

The Apollo Domain windowing system was DM. It ran about 10X faster than
X Windows since it wrote straight to the hardware.
https://en.wikipedia.org/wiki/DM_(windowing_system)

Sun's SunView was actually pretty good.

Lynn

[Jorgen Grahn]

On Thu, 2018-01-18, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> "Fred.Zwarts" <F.Zw...@KVI.nl> spake the secret code
> <p3n0lv$1krc$1...@gioia.aioe.org> thusly:
>
>>OpenVMS, once a popular OS, started with its own windowing system, but later
>>moved to X-Windows.
>
> Off the top of my head companies/proprietary window systems killed off
> by the X Window System:
>
> Sun's SunView
> Sun's NeWS
> SGI's 4Sight
> SGI's MEX
> DEC (DECwindows was their name for their X Window System
> implementation, IIRC); I think you're right that they had a
> proprietary thing before but I don't know what that was called.
> Hewlett-Packard
> Domain/OS from Apollo had something, I can't remember what it was called.
> It might not have had a distinct name for the GUI part.
> ...and of course there are many smaller manufacturers that had their
> own thing.
>
> It's really quite successful that X managed to kill off all these
> proprietary islands of functionality and unify them into a single
> environment, both for users and developers.

On the other hand, the widget toolkits on top of X11 are quite
different in user interface and API. And then there's the various
desktop environments, trying to create their own universes ...

X11 did win, but I'm not sure it helped programmers and users that
much.

/Jorgen

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

[Ian Collins]

It did to the extent that those of us working on more than one flavour
of UNIX could reuse code. It also gave rise to Motif on most UNIX
platforms.

--
Ian.

[Fred.Zwarts]

"Richard" schreef in bericht news:p3p0mj$m4m$1...@news.xmission.com...

> ...

>Off the top of my head companies/proprietary window systems killed off
>by the X Window System:
>

> ...

>
>DEC (DECwindows was their name for their X Window System
>implementation, IIRC); I think you're right that they had a
>proprietary thing before but I don't know what that was called.
>Hewlett-Packard

No, DECwindwos was the name of the X-Windows implementation. The native
Windowing system was called VWS (VAX Workstation Software) with its
programming interface UIS. It was much faster then DECwindows, but it was
not based on a client/server model.
http://h41379.www4.hpe.com/wizard/wiz_9916.html

[Scott Lurndal]

At the expense of network transparancy, one of the greatest
strengths (and weaknesses) of X11Rn.

[Richard]

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

Lynn McGuire <lynnmc...@gmail.com> spake the secret code

<p3p4gp$gm1$1...@dont-email.me> thusly:

>On 1/17/2018 8:27 PM, Richard wrote:

>> Domain/OS from Apollo had something, I can't remember what it was called.
>> It might not have had a distinct name for the GUI part.

>The Apollo Domain windowing system was DM. It ran about 10X faster than
>X Windows since it wrote straight to the hardware.

Cool, thanks for that.

There's no reason that their X implementation couldn't have done the
same thing, BTW. The X server implementation is fairly layered,
making it easy to get an implementation working (all it really needs
is getpixel and putpixel at its lowest layer). To get things running
fast, you have to put more work into it. I don't know if Apollo
didn't want to invest the effort in order to keep DM looking good or
if they couldn't afford to invest the effort. By the time X11 came
along, I think Apollo was on its last legs and about to be acquired by
HP.

>Sun's SunView was actually pretty good.

Another one I found for the list was HP Windows/9000.
<http://bitsavers.trailing-edge.com/pdf/hp/9000_hpux/2.x/97069-90000_HP_Windows_9000_Users_Manual_Dec85.pdf>

[Richard]

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

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

I agree that until Motif there wasn't a decent widget set available
(Athena widgets were too simplistic and boring looking). The general
intent was that Common Desktop Environment was going to smooth out the
usability quirks between systems, but I don't know how successful that
was in the end because around that time I switched to Windows and
stopped tracking X Window System stuff on a day-to-day basis.

Xt was interesting in that it was an object-oriented layer glued on
top of C by means of convention. One thing I think that held X based
toolkits back is that we never got an officially blessed C++ API from
the X Consortium. InterViews came really close, but didn't get the
final push.

[Jorgen Grahn]

On Thu, 2018-01-18, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
> <slrnp60ig2.e...@frailea.sa.invalid> thusly:
>
>>On Thu, 2018-01-18, Richard wrote:
>
>>> It's really quite successful that X managed to kill off all these
>>> proprietary islands of functionality and unify them into a single
>>> environment, both for users and developers.
>>
>>On the other hand, the widget toolkits on top of X11 are quite
>>different in user interface and API. And then there's the various
>>desktop environments, trying to create their own universes ...
>>
>>X11 did win, but I'm not sure it helped programmers and users that
>>much.
>
> I agree that until Motif there wasn't a decent widget set available
> (Athena widgets were too simplistic and boring looking).

For the record, it was Ian Collins who brought up Motif as a good
thing.

For me, it was the only widget toolkit I ever programmed myself, but I
never liked it much. (Then I was disappointed when I moved to Linux,
and it wasn't easily available there, before Lesstif.)

> The general intent was that Common Desktop Environment was going to
> smooth out the usability quirks between systems, but I don't know
> how successful that was in the end because around that time I
> switched to Windows and stopped tracking X Window System stuff on a
> day-to-day basis.

From my point of view, CDE was the first in a succession of desktop
environments which tried to take over ... that's still going on, AFAICT.

One good thing is it's still possible to dodge them. My desktop is a
traditional X11 one with just a window manager; many others use the
various tiling window managers.

> Xt was interesting in that it was an object-oriented layer glued on
> top of C by means of convention. One thing I think that held X based
> toolkits back is that we never got an officially blessed C++ API from
> the X Consortium. InterViews came really close, but didn't get the
> final push.

[Mr Flibble]

Widgets should not be part of a window manager's remit which is why X11 won.

The closest we will get to a perfect C++ widget library is the widget
library in neoGFX.

/Flibble

--
"Suppose it’s all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I’d say, bone cancer in children? What’s that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It’s not right, it’s utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That’s what I would say."

[Alexander Huszagh]

Think about how far frameworks like Qt took to develop, and how far from polished they are. Qt is excellent, a work in progress, and a massive company is required to develop and maintain it. In addition, the virtual interfaces and lack of custom allocators would be a strict no in the C++ standard library, yet is the closest implementation we have to a working, cross-platform, C++ GUI framework that is clean and performant.

I would like unicorns, but I doubt I will get them.

[Mr Flibble]

On 20/01/2018 23:50, Alexander Huszagh wrote:
> Think about how far frameworks like Qt took to develop, and how far from polished they are. Qt is excellent, a work in progress, and a massive company is required to develop and maintain it. In addition, the virtual interfaces and lack of custom allocators would be a strict no in the C++ standard library, yet is the closest implementation we have to a working, cross-platform, C++ GUI framework that is clean and performant.
>
> I would like unicorns, but I doubt I will get them.

My GUI library, neoGFX, may meet your requirements:

http://neogfx.org

The intention is for neoGFX is be a better quality and cheaper
alternative to the bloated, baggage ridden antiquated Qt.