"My CppCon 2018 talk title and abstract" 2018-09-14 by Herb Sutter

[Lynn McGuire]

"My CppCon 2018 talk title and abstract" 2018-09-14 by Herb Sutter

https://herbsutter.com/2018/09/14/my-cppcon-2018-talk-title-and-abstract/

"Thoughts on a more powerful and simpler C++ (5 of N)"

"Perhaps the most important thing we can do for C++ at this point in its
evolution is to make sure we preserve its core strengths while also
directing its evolution in ways that make it simpler to use. That is my
own opinion at least, and so this talk starts with a perspective
question: What “is C++,” really? The language continues to evolve and
change; as it does so, how can we be sure we’re picking C++ evolutionary
improvements that not only don’t lose its “C++-ic” qualities, but make
it a better C++ than ever?"

Lynn

[Thiago Adams]

I think Herb is being very consistent along the years
and I like the subjects he choose.

[bol...@cylonhq.com]

On Mon, 17 Sep 2018 11:53:41 -0700 (PDT)
Thiago Adams <thiago...@gmail.com> wrote:
>On Friday, September 14, 2018 at 5:33:21 PM UTC-3, Lynn McGuire wrote:
>> "My CppCon 2018 talk title and abstract" 2018-09-14 by Herb Sutter

>> =20
>> https://herbsutter.com/2018/09/14/my-cppcon-2018-talk-title-and-abstract/
>>=20

>> "Thoughts on a more powerful and simpler C++ (5 of N)"

>>=20
>> "Perhaps the most important thing we can do for C++ at this point in its=
>=20
>> evolution is to make sure we preserve its core strengths while also=20
>> directing its evolution in ways that make it simpler to use. That is my=
>=20
>> own opinion at least, and so this talk starts with a perspective=20
>> question: What =E2=80=9Cis C++,=E2=80=9D really? The language continues t=
>o evolve and=20
>> change; as it does so, how can we be sure we=E2=80=99re picking C++ evolu=
>tionary=20
>> improvements that not only don=E2=80=99t lose its =E2=80=9CC++-ic=E2=80=
>=9D qualities, but make=20

>> it a better C++ than ever?"

>>=20
>> Lynn
>
>I think Herb is being very consistent along the years=20

>and I like the subjects he choose.

Its time for C++ to be left alone. I fail to see the point in playing catch
up with all the new kids on the block since people who want that sort of
functionality arn't going to even look at C++. All that has resulted so far is
a dogs dinner language with bits of stuff thrown in to an incoherent whole with
a syntax that in recent years is now close to threatening Perl for the explosion
in a typewriter factory award.

C++ has its niche as an OO and generic version of C and will continue to be
used on to-the-metal and high speed projects, but for most other things these
days its been superceded. Notice that almost none of the "serverless" cloud
systems offer C or C++ as supported languages and unfortunately thats the way
development is headed these days.

Perhaps instead of adding yet more crap that no one will use the committee
should first concentrate on getting it to play nice with C99. They've only
had 19 years.

[David Brown]

Languages used on servers are often PHP, Python, etc. There are good
reasons for this - these languages are dynamic, managed languages with
good string support and with standard libraries for handling network
protocols of all sorts.

C++ is gaining some of the features that make these languages popular.
It won't get them all - there are always going to be good reasons for
choosing Python rather than C++. But that doesn't mean C++ can't
benefit from looking at them and thinking how it would be best to solve
the same problems in the C++ world.

Python has duck-typing, which makes it easy to use widely different
types in the same context. C++ has structural typing, so you need a
common base class if you want common functions - or you need templates
that have no obvious connection to the duck-like features you want.
Enter "concepts" that give you this, and you have many of the benefits
of duck-typing in a statically compiled and checked language.

Python has strings, dictionaries, lists, with automatic memory
management. Enter the C++ standard library which gives you these -
albeit with a somewhat less pleasant syntax.

Python has introspection and can add fields to classes and objects at
run-time, making it simple to write things like JSON serialisers and
deserialisers, or match classes to database tables. Enter C++
introspection and metaclasses, coming Real Soon Now!.

(Conversely, Python is acquiring type annotation in functions and other
features for "compile-time" checking.)


C++ has gone through a period of adding features that are complicated,
powerful, and difficult to understand. We have seen lots of creative
but obtuse solutions to problems - this lets experts create very useful
classes for the mortal C++ programmers to use. What we are seeing now
is a move towards a simplification of how C++ can be written while
making steadily more advanced features.

As a fine example, look at the "safe boolean idiom". It used to be
/horrendous/ - you need advanced C++ skills just to use it, and a very
warped brain to have come up with the solution in the first place. Now,
you just add "explicit" to the bool operator - clear, simple and easy
for everyone.

Look at template code today - it is often full of enable_if's, SFINAE
code, at other such messy and complicated details. Once concepts are
established, most of that just disappears, along with much of the ugly
syntax used to declare template functions.

Metaclasses will be another revolution in letting people write C++ code
in a simpler and clearer way, and letting people write more useful
libraries.


The C++ language has become more complicated and gained new features, in
order to make C++ /programming/ easier. That's a win as far as I can see.

>
> Perhaps instead of adding yet more crap that no one will use the committee
> should first concentrate on getting it to play nice with C99. They've only
> had 19 years.
>

I believe C++20 will have designated initialisers, which is nice - and
could have been copied from C99 long ago. There are a few other C99
features that could be pulled in, but not many - and most are already
supported as extensions by every C++ compiler except MSVC.

[bol...@cylonhq.com]

On Tue, 18 Sep 2018 11:13:48 +0200
David Brown <david...@hesbynett.no> wrote:
>Languages used on servers are often PHP, Python, etc. There are good
>reasons for this - these languages are dynamic, managed languages with
>good string support and with standard libraries for handling network
>protocols of all sorts.

And they can be more easily sandboxed and restricted. I suspect the real
reason for no C or C++ support in serverless systems (Amazon does support it
but only on EC2 which is little more than a fancy VM host anyway) is that
these companies don't want raw binaries running on their systems because A) it
could be a security risk and B) it might restrict them to a particular
processor architecture as perhaps in the future they might switch to ARM for
example.

>choosing Python rather than C++. But that doesn't mean C++ can't
>benefit from looking at them and thinking how it would be best to solve
>the same problems in the C++ world.

Why? As I said, people who want to solve these sorts of problems are not going
to bother with C++ since the language is so large now no sane person is going
to bother to learn it from scratch. If I didn't know it already I certainly
wouldn't.

>that have no obvious connection to the duck-like features you want.
>Enter "concepts" that give you this, and you have many of the benefits
>of duck-typing in a statically compiled and checked language.

If you want duck typing just use python.

>Python has strings, dictionaries, lists, with automatic memory
>management. Enter the C++ standard library which gives you these -
>albeit with a somewhat less pleasant syntax.

Which has been around for decades and is not part of the language per-se.

>Python has introspection and can add fields to classes and objects at
>run-time, making it simple to write things like JSON serialisers and
>deserialisers, or match classes to database tables. Enter C++
>introspection and metaclasses, coming Real Soon Now!.

Whoppee, I can hardly wait. Serialised json is just json. Its not binary, it
doesn't have any word byte order conversions to worry about nor does it store
BLOBs. If you simply want to compress it then you could do that in C, never
mind C++.

>As a fine example, look at the "safe boolean idiom". It used to be

Not only have I never used that idiom, I've never even written code that
needed it. A lot of these "solutions" are problems created by over complicated
code written by people trying to be clever rather than solving the actual
problem at hand. Hands up how many people have seen an entire factory framework
when a simple STL container would have done the same job?

>Look at template code today - it is often full of enable_if's, SFINAE

Had to look up enable_if, never heard of it. If your templates get that
complex then maybe for sanitys sake just bin them and use non templated
functions and classes even if it means more code.

>Metaclasses will be another revolution in letting people write C++ code
>in a simpler and clearer way, and letting people write more useful
>libraries.

Yeah, right.

>The C++ language has become more complicated and gained new features, in
>order to make C++ /programming/ easier. That's a win as far as I can see.

Yes, I can see from the enable_if example page how it makes programming
easier.

https://en.cppreference.com/w/cpp/types/enable_if

I can't even be bothered to figure it out. Frankly I'd sooner code in
assembler again than have to fuck about with that sort of mess.

[David Brown]

On 18/09/18 11:33, bol...@cylonHQ.com wrote:
> On Tue, 18 Sep 2018 11:13:48 +0200
> David Brown <david...@hesbynett.no> wrote:
>> Languages used on servers are often PHP, Python, etc. There are good
>> reasons for this - these languages are dynamic, managed languages with
>> good string support and with standard libraries for handling network
>> protocols of all sorts.
>
> And they can be more easily sandboxed and restricted. I suspect the real
> reason for no C or C++ support in serverless systems (Amazon does support it
> but only on EC2 which is little more than a fancy VM host anyway) is that
> these companies don't want raw binaries running on their systems because A) it
> could be a security risk and B) it might restrict them to a particular
> processor architecture as perhaps in the future they might switch to ARM for
> example.
>

That may well be the case - you'd have to ask those companies.

>> choosing Python rather than C++. But that doesn't mean C++ can't
>> benefit from looking at them and thinking how it would be best to solve
>> the same problems in the C++ world.
>
> Why? As I said, people who want to solve these sorts of problems are not going
> to bother with C++ since the language is so large now no sane person is going
> to bother to learn it from scratch. If I didn't know it already I certainly
> wouldn't.

By "problems", I don't mean the overall task of the program - I mean
particular bits of it. Like "how do we make this data structure in a
way that is efficient and won't leak memory".

>
>> that have no obvious connection to the duck-like features you want.
>> Enter "concepts" that give you this, and you have many of the benefits
>> of duck-typing in a statically compiled and checked language.
>
> If you want duck typing just use python.

If you want fast code with static checking, /and/ you want some aspects
of duck-typing, use C++ with concepts.

I use Python when I want Python, and C or C++ when I want those
languages. There are times when using one language that I think "I wish
it was easy to do this particular thing as it is in that other
language". It is a /good/ thing that languages take inspiration from
each other to see how they can be better for developers.

>
>> Python has strings, dictionaries, lists, with automatic memory
>> management. Enter the C++ standard library which gives you these -
>> albeit with a somewhat less pleasant syntax.
>
> Which has been around for decades and is not part of the language per-se.
>
>> Python has introspection and can add fields to classes and objects at
>> run-time, making it simple to write things like JSON serialisers and
>> deserialisers, or match classes to database tables. Enter C++
>> introspection and metaclasses, coming Real Soon Now!.
>
> Whoppee, I can hardly wait. Serialised json is just json. Its not binary, it
> doesn't have any word byte order conversions to worry about nor does it store
> BLOBs. If you simply want to compress it then you could do that in C, never
> mind C++.

We all know what JSON is. Would it not be lovely to be able to take an
object in C++ and pass it to a generic "toJson" function and have its
members serialised - recursively as needed - without having to write
specialised functions for every single class in the program?

>
>> As a fine example, look at the "safe boolean idiom". It used to be
>
> Not only have I never used that idiom, I've never even written code that
> needed it. A lot of these "solutions" are problems created by over complicated
> code written by people trying to be clever rather than solving the actual
> problem at hand. Hands up how many people have seen an entire factory framework
> when a simple STL container would have done the same job?
>
>> Look at template code today - it is often full of enable_if's, SFINAE
>
> Had to look up enable_if, never heard of it. If your templates get that
> complex then maybe for sanitys sake just bin them and use non templated
> functions and classes even if it means more code.
>

Have you ever looked at how the standard library is implemented? You
may not need to use safe boolean idioms, enable_if, and the rest in your
code - but I'm guessing that you have at least used standard containers
that /do/ use this kind of thing for their implementation. If you don't
want to use these features of the language, that's absolutely fine - but
don't try to tell others that they are useless, or that they could not
be replaced with something better, just because /you/ don't understand them.

[bol...@cylonhq.com]

On Tue, 18 Sep 2018 12:26:07 +0200
David Brown <david...@hesbynett.no> wrote:
>On 18/09/18 11:33, bol...@cylonHQ.com wrote:
>>> that have no obvious connection to the duck-like features you want.
>>> Enter "concepts" that give you this, and you have many of the benefits
>>> of duck-typing in a statically compiled and checked language.
>>
>> If you want duck typing just use python.
>
>If you want fast code with static checking, /and/ you want some aspects
>of duck-typing, use C++ with concepts.

Or use Objective-C which has had it since it was created. Oddly though that
language never took off outside the apple ecosystem.

>language". It is a /good/ thing that languages take inspiration from
>each other to see how they can be better for developers.

You say taking inspiration, I say a one-size-fits-all type language which
will never work.

>> Whoppee, I can hardly wait. Serialised json is just json. Its not binary, it
>
>> doesn't have any word byte order conversions to worry about nor does it store
>
>> BLOBs. If you simply want to compress it then you could do that in C, never
>> mind C++.
>
>We all know what JSON is. Would it not be lovely to be able to take an
>object in C++ and pass it to a generic "toJson" function and have its
>members serialised - recursively as needed - without having to write
>specialised functions for every single class in the program?

It would, except it'll never be implemented fully. Why? Pointers. Apart from
not being able to figure out the pointer type unless extra functionality is
added to the runtime system (typeid is no good as you have to know beforehand
what you're checking against), the pointer itself could be pointing at anything
or anywhere. Eg shared memory, of which the structure is only known to the
program logic, not the compiler or any library function and could in turn have
pointers itself. Serialising that would simply produce a meaningless list of
values that could be invalid in any other process.

So, even if built in serialisation is added it'll be rather restricted.

>> Had to look up enable_if, never heard of it. If your templates get that
>> complex then maybe for sanitys sake just bin them and use non templated
>> functions and classes even if it means more code.
>>
>
>Have you ever looked at how the standard library is implemented? You

Once, it was enough.

>may not need to use safe boolean idioms, enable_if, and the rest in your
>code - but I'm guessing that you have at least used standard containers
>that /do/ use this kind of thing for their implementation. If you don't

Since enable_if is C++ 2011 they quite obviously don't (or didn't) as the STL
has been around since the 90s. Seems to me it is nothing more than yet another
syntatic hack to get around the poor initial syntactic and lexical design of
some aspect of the language rather than anything that will aid in developing
actually useful code or algorithms.

[Ian Collins]

On 18/09/18 23:08, bol...@cylonHQ.com wrote:
>
> Since enable_if is C++ 2011 they quite obviously don't (or didn't) as the STL
> has been around since the 90s. Seems to me it is nothing more than yet another
> syntatic hack to get around the poor initial syntactic and lexical design of
> some aspect of the language rather than anything that will aid in developing
> actually useful code or algorithms.

Blah blah blah... are you related to BartC who whinges on about C in c.l.c?

--
Ian.

[bol...@cylonhq.com]

Oh look, another mouth breather has popped up.

[David Brown]

On 18/09/18 13:08, bol...@cylonHQ.com wrote:
> On Tue, 18 Sep 2018 12:26:07 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 18/09/18 11:33, bol...@cylonHQ.com wrote:
>>>> that have no obvious connection to the duck-like features you want.
>>>> Enter "concepts" that give you this, and you have many of the benefits
>>>> of duck-typing in a statically compiled and checked language.
>>>
>>> If you want duck typing just use python.
>>
>> If you want fast code with static checking, /and/ you want some aspects
>> of duck-typing, use C++ with concepts.
>
> Or use Objective-C which has had it since it was created. Oddly though that
> language never took off outside the apple ecosystem.
>
>> language". It is a /good/ thing that languages take inspiration from
>> each other to see how they can be better for developers.
>
> You say taking inspiration, I say a one-size-fits-all type language which
> will never work.

Nobody has suggested a one-size-fits-all language. People have merely
suggesting adding some more features to a useful and flexible language.

>
>>> Whoppee, I can hardly wait. Serialised json is just json. Its not binary, it
>>
>>> doesn't have any word byte order conversions to worry about nor does it store
>>
>>> BLOBs. If you simply want to compress it then you could do that in C, never
>>> mind C++.
>>
>> We all know what JSON is. Would it not be lovely to be able to take an
>> object in C++ and pass it to a generic "toJson" function and have its
>> members serialised - recursively as needed - without having to write
>> specialised functions for every single class in the program?
>
> It would, except it'll never be implemented fully. Why? Pointers. Apart from
> not being able to figure out the pointer type unless extra functionality is
> added to the runtime system (typeid is no good as you have to know beforehand
> what you're checking against), the pointer itself could be pointing at anything
> or anywhere. Eg shared memory, of which the structure is only known to the
> program logic, not the compiler or any library function and could in turn have
> pointers itself. Serialising that would simply produce a meaningless list of
> values that could be invalid in any other process.
>
> So, even if built in serialisation is added it'll be rather restricted.

Of course it would be restricted (and pointers are not the main issue -
especially since they could probably be avoided in most cases). But it
would still be very, very useful.

>
>>> Had to look up enable_if, never heard of it. If your templates get that
>>> complex then maybe for sanitys sake just bin them and use non templated
>>> functions and classes even if it means more code.
>>>
>>
>> Have you ever looked at how the standard library is implemented? You
>
> Once, it was enough.
>
>> may not need to use safe boolean idioms, enable_if, and the rest in your
>> code - but I'm guessing that you have at least used standard containers
>> that /do/ use this kind of thing for their implementation. If you don't
>
> Since enable_if is C++ 2011 they quite obviously don't (or didn't) as the STL
> has been around since the 90s. Seems to me it is nothing more than yet another
> syntatic hack to get around the poor initial syntactic and lexical design of
> some aspect of the language rather than anything that will aid in developing
> actually useful code or algorithms.
>

You might want to look at what has changed over the years, before
deciding that what you had in the 1990's was enough. And "enable_if"
does not actually do anything that could not be done before - it's usual
definition is simple enough and valid for C++98 (I think). But it
standardises a common pattern with a recognizable name, making such
template code easier to read, write and maintain..

Many new C++ features are not about allowing you to do something that
you could not do earlier - they are about making them simple, clearer,
and easier to work with.

Let's take a little example. Suppose you want a function "roughlyEqual"
that compares integers or floats, using a different algorithm in each
case. With concepts, you can define a couple of concepts and write out
the functions neatly. (There are severe limitations in this example -
it is a taster, nothing more.)

You can paste this into <https://godbolt.org> and compile with "-fconcepts".


#include <type_traits>
#include <cstdlib>

// These "concepts" would probably be part of the standard library

template <typename T>
concept bool Floating_Point =
std::is_floating_point<T>::value;

template <typename T>
concept bool Integer =
std::is_integral<T>::value;


// Here we have two template functions using the concepts

bool roughlyEqual(Floating_Point a, Floating_Point b) {
return abs(a - b) < 0.0001;
}

bool roughlyEqual(Integer a, Integer b) {
return a == b;
}

// And some test code

bool test1(void) {
return roughlyEqual(2, 5);
}

bool test2(void) {
return roughlyEqual(2, 2);
}

bool test3(void) {
return roughlyEqual(2.0, 5.0);
}

bool test4(void) {
return roughlyEqual(2.0, 2.000001);
}


If you try "roughlyEqual("a", "b")", it will fail to compile - which is
the result you want.


You can write the roughlyEqual template functions using SFINAE, using
enable_if to make it easier:

template <typename T>
typename std::enable_if<std::is_integral<T>::value, bool>::type
roughlyEqual(T a, T b) {
return a == b;
}

template <typename T>
typename std::enable_if<std::is_floating_point<T>::value, bool>::type
roughlyEqual(T a, T b) {
return abs(a - b) < 0.0001;
}


To me, the concept code is a lot simpler.

[David Brown]

What do you think "mouth breather" means? It is about as smart as
saying "Oh look, another left-hander" or "Oh look, another person with
big ears". It simply makes you look rude, thoughtless and ignorant -
with a penchant for really stupid insults.

[bol...@cylonhq.com]

On Tue, 18 Sep 2018 14:01:35 +0200
David Brown <david...@hesbynett.no> wrote:

>On 18/09/18 13:08, bol...@cylonHQ.com wrote:
>> You say taking inspiration, I say a one-size-fits-all type language which
>> will never work.
>
>Nobody has suggested a one-size-fits-all language. People have merely

That seems to be the way C++ is heading. And anyone who's used a large
swiss army knife knows, they're really not particularly good at anything.
Including being a knife.

>Let's take a little example. Suppose you want a function "roughlyEqual"
>that compares integers or floats, using a different algorithm in each
>case. With concepts, you can define a couple of concepts and write out
>the functions neatly. (There are severe limitations in this example -
>it is a taster, nothing more.)

No kidding. You can do exactly the same using standard polymorphism:

bool roughlyEqual(int a, int b)
{
return a == b;
}


bool roughlyEqual(float a, float b)
{
return fabs(a - b) < 0.001;
}

[bol...@cylonhq.com]

On Tue, 18 Sep 2018 14:05:39 +0200
David Brown <david...@hesbynett.no> wrote:
>On 18/09/18 13:50, bol...@cylonHQ.com wrote:
>> On Tue, 18 Sep 2018 23:17:05 +1200
>> Ian Collins <ian-...@hotmail.com> wrote:
>>> On 18/09/18 23:08, bol...@cylonHQ.com wrote:
>>>>
>>>> Since enable_if is C++ 2011 they quite obviously don't (or didn't) as the
>STL
>>>
>>>> has been around since the 90s. Seems to me it is nothing more than yet
>>> another
>>>> syntatic hack to get around the poor initial syntactic and lexical design
>of
>>>> some aspect of the language rather than anything that will aid in
>developing
>>>> actually useful code or algorithms.
>>>
>>> Blah blah blah... are you related to BartC who whinges on about C in c.l.c?
>>
>> Oh look, another mouth breather has popped up.
>>
>
>What do you think "mouth breather" means? It is about as smart as

I know what it means, but why not grace us with your clearly sage like
wisdom and tell us.

>saying "Oh look, another left-hander" or "Oh look, another person with
>big ears". It simply makes you look rude, thoughtless and ignorant -
>with a penchant for really stupid insults.

Except those are being rude about physical aspects of someone, not their
behaviour which is quite different. Either that mind numbingly clear
distinction is beyond you or you're just some sad little SJW looking to be
offended. Either way, I couldn't give a shit. If you are offended then tough,
grow a pair and get over it. Now close your mouth and stop dribbling.

[David Brown]

On 18/09/18 15:12, bol...@cylonHQ.com wrote:
> On Tue, 18 Sep 2018 14:05:39 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 18/09/18 13:50, bol...@cylonHQ.com wrote:
>>> On Tue, 18 Sep 2018 23:17:05 +1200
>>> Ian Collins <ian-...@hotmail.com> wrote:
>>>> On 18/09/18 23:08, bol...@cylonHQ.com wrote:
>>>>>
>>>>> Since enable_if is C++ 2011 they quite obviously don't (or didn't) as the
>> STL
>>>>
>>>>> has been around since the 90s. Seems to me it is nothing more than yet
>>>> another
>>>>> syntatic hack to get around the poor initial syntactic and lexical design
>> of
>>>>> some aspect of the language rather than anything that will aid in
>> developing
>>>>> actually useful code or algorithms.
>>>>
>>>> Blah blah blah... are you related to BartC who whinges on about C in c.l.c?
>>>
>>> Oh look, another mouth breather has popped up.
>>>
>>
>> What do you think "mouth breather" means? It is about as smart as
>
> I know what it means, but why not grace us with your clearly sage like
> wisdom and tell us.

You don't need a lot of wisdom here - a "mouth breather" is someone who
breaths through their mouths a lot, rather than through their nose.
There can be many reasons for this, such as simply having a physically
narrow air passage in the upper nose (this is an inheritable trait).

>
>> saying "Oh look, another left-hander" or "Oh look, another person with
>> big ears". It simply makes you look rude, thoughtless and ignorant -
>> with a penchant for really stupid insults.
>
> Except those are being rude about physical aspects of someone, not their
> behaviour which is quite different.

Having narrow nasal air passages, leading to mouth breathing, is a
physical aspect of the person.

A little googling showed me that some American's think "mouth breathing"
is an insult suggesting someone is stupid. It's a bit like calling
someone "blond" when they mean stupid - it merely shows the
name-caller's ignorance and general rudeness.

> Either that mind numbingly clear
> distinction is beyond you or you're just some sad little SJW looking to be
> offended. Either way, I couldn't give a shit. If you are offended then tough,
> grow a pair and get over it. Now close your mouth and stop dribbling.
>

I think Ian is wrong to compare you to Bart. Bart might be stubbornly
and wilfully ignorant, but he is not the unpleasant little turd of a
human being that you give yourself out to be.

[Paavo Helde]

On 18.09.2018 12:33, bol...@cylonHQ.com wrote:
> On Tue, 18 Sep 2018 11:13:48 +0200
> David Brown <david...@hesbynett.no> wrote:

[...]

> Why? As I said, people who want to solve these sorts of problems are not going
> to bother with C++ since the language is so large now no sane person is going
> to bother to learn it from scratch. If I didn't know it already I certainly
> wouldn't.

As it has become clear by now you do not know very much about C++ anyway
so this does not look like a very strong reason.

>
>> As a fine example, look at the "safe boolean idiom". It used to be
>
> Not only have I never used that idiom, I've never even written code that
> needed it.

Let me guess, this means you have never written a conversion operator
for a class and do not understand why somebody would need one.

> Had to look up enable_if, never heard of it.

No wonder you are thinking C++ is "an OO and generic version of C" (a
quote from your previous post).

> I can't even be bothered to figure it out. Frankly I'd sooner code in
> assembler again than have to fuck about with that sort of mess.

That's all nice and fine, you don't need to know or use the whole
language. On the other hand, why do you feel you are entitled to express
strong opinions about in which direction the language should evolve in
spite of your ignorance about the current state?

[David Brown]

Polymorphism - function overloading - works on structural typing.
Concepts work on features. There is a /vast/ difference.

[bol...@cylonhq.com]

On Tue, 18 Sep 2018 15:29:59 +0200
David Brown <david...@hesbynett.no> wrote:

>On 18/09/18 15:12, bol...@cylonHQ.com wrote:
>> I know what it means, but why not grace us with your clearly sage like
>> wisdom and tell us.
>
>You don't need a lot of wisdom here - a "mouth breather" is someone who
>breaths through their mouths a lot, rather than through their nose.

Noooo! Say it ain't so!! I bow down before your god like intellect in this
matter!

>There can be many reasons for this, such as simply having a physically
>narrow air passage in the upper nose (this is an inheritable trait).

Or because a lot of dumb people have a tendency to have their mouth open when
thinking. Or just when chewing gum.

>Having narrow nasal air passages, leading to mouth breathing, is a

Yeah, I'm sure its that.

>A little googling showed me that some American's think "mouth breathing"
>is an insult suggesting someone is stupid. It's a bit like calling

Well I'm not american so its somewhat more widespread.

>I think Ian is wrong to compare you to Bart. Bart might be stubbornly
>and wilfully ignorant, but he is not the unpleasant little turd of a
>human being that you give yourself out to be.

If being an unpleasant turd means I won't roll over and mea culpa for your
self righteous virtue signalling bullshit then guilty as charged.

[bol...@cylonhq.com]

On Tue, 18 Sep 2018 16:31:32 +0300
Paavo Helde <myfir...@osa.pri.ee> wrote:
>On 18.09.2018 12:33, bol...@cylonHQ.com wrote:
>> Not only have I never used that idiom, I've never even written code that
>> needed it.
>
>Let me guess, this means you have never written a conversion operator
>for a class and do not understand why somebody would need one.

I have, never needed that though.

>> Had to look up enable_if, never heard of it.
>
>No wonder you are thinking C++ is "an OO and generic version of C" (a
>quote from your previous post).

How would you describe it then?

>> I can't even be bothered to figure it out. Frankly I'd sooner code in
>> assembler again than have to fuck about with that sort of mess.
>
>That's all nice and fine, you don't need to know or use the whole
>language. On the other hand, why do you feel you are entitled to express
>strong opinions about in which direction the language should evolve in
>spite of your ignorance about the current state?

Because anyone who uses any language eventually has to learn most of it
simply because code you end up maintaining will have it in and it will get
asked in job interviews. The larger the language gets the harder this becomes
and when you have to be current in more than 1 language it becomes onorous.

[bol...@cylonhq.com]

On Tue, 18 Sep 2018 15:31:59 +0200

For your example its same end result. You'll need a better one to convince me.

[David Brown]

I would never be able to convince you - you have already decided that
you don't like C++, and in particular you don't like the newer features
that you don't understand.

[Alf P. Steinbach]

On 18.09.2018 15:31, Paavo Helde wrote:
> On 18.09.2018 12:33, bol...@cylonHQ.com wrote:
>> On Tue, 18 Sep 2018 11:13:48 +0200
>> David Brown <david...@hesbynett.no> wrote:
> [...]
>>

>>> As a fine example, look at the "safe boolean idiom".  It used to be
>>
>> Not only have I never used that idiom, I've never even written code that
>> needed it.
>
> Let me guess, this means you have never written a conversion operator
> for a class and do not understand why somebody would need one.

I'm with “Boltar” on that one.

In its day the safe bool idiom was someone's convoluted and intricate
way to have a not-so-unsafe implicit conversion to bool so as to be able
to write terse but unclear code, e.g. `if( stream )` instead of the more
verbose but more clear `if( not stream.in_fail_mode() )`.

`explicit` is not the answer. Besides it's a bit of a misnomer, an
implicitly invoked `explicit` conversion. Naming it is much better.


Cheers!,

- Alf

[Paavo Helde]

On 19.09.2018 2:56, Alf P. Steinbach wrote:
> On 18.09.2018 15:31, Paavo Helde wrote:
>> On 18.09.2018 12:33, bol...@cylonHQ.com wrote:
>>> On Tue, 18 Sep 2018 11:13:48 +0200
>>> David Brown <david...@hesbynett.no> wrote:
>> [...]
>>>
>>>> As a fine example, look at the "safe boolean idiom". It used to be
>>>
>>> Not only have I never used that idiom, I've never even written code that
>>> needed it.
>>
>> Let me guess, this means you have never written a conversion operator
>> for a class and do not understand why somebody would need one.
>
> I'm with “Boltar” on that one.
>
> In its day the safe bool idiom was someone's convoluted and intricate
> way to have a not-so-unsafe implicit conversion to bool so as to be able
> to write terse but unclear code, e.g. `if( stream )` instead of the more
> verbose but more clear `if( not stream.in_fail_mode() )`.

Operator bool helps to limit the scope of variables which is a good thing:

if (auto stream = std::ifstream("c:/tmp/foo.bar")) { //...

if (auto ptr = someWeakPtr.lock()) { // ...

Conversion operators in general are not so useful, but sometimes they
are handy, e.g. for wrapping primitive types like ints for special
behavior. For example, one might use a simple mod 8 int type for
considering the possible 8 directions in some 2D pixel level algorithm.
Instead of declaring a bunch of arithmetic operations on the type one
can just use int for arithmetic and normalize the result into 0..7 range
in the ctor:

Direction dir1 = 0; // north
Direction dir2 = dir1 + 2; // east
Direction dir3 = dir1 - 2*dir2; // west

With named conversion functions the last line would become too verbose
for my taste, considering that the low-level algorithm would be littered
with those conversions:

Direction dir3 = dir1.to_int() - 2*dir2.to_int();

[Alf P. Steinbach]

On 19.09.2018 07:11, Paavo Helde wrote:
> On 19.09.2018 2:56, Alf P. Steinbach wrote:
>> On 18.09.2018 15:31, Paavo Helde wrote:
>>> On 18.09.2018 12:33, bol...@cylonHQ.com wrote:
>>>> On Tue, 18 Sep 2018 11:13:48 +0200
>>>> David Brown <david...@hesbynett.no> wrote:
>>> [...]
>>>>
>>>>> As a fine example, look at the "safe boolean idiom".  It used to be
>>>>
>>>> Not only have I never used that idiom, I've never even written code
>>>> that
>>>> needed it.
>>>
>>> Let me guess, this means you have never written a conversion operator
>>> for a class and do not understand why somebody would need one.
>>
>> I'm with “Boltar” on that one.
>>
>> In its day the safe bool idiom was someone's convoluted and intricate
>> way to have a not-so-unsafe implicit conversion to bool so as to be able
>> to write terse but unclear code, e.g. `if( stream )` instead of the more
>> verbose but more clear `if( not stream.in_fail_mode() )`.
>
> Operator bool helps to limit the scope of variables which is a good thing:
>
> if (auto stream = std::ifstream("c:/tmp/foo.bar")) { //...

For comparisons with the following examples, the way I format it it
would look like

if( auto stream = ifstream( filepath ) )
{
//...
}

So many programmers are confused about stream.good() and stream.fail(),
which are not opposites. With an explicit call of .fail() they know
what's checked. An explicit call to .fail() adds more source code,
that's a cost, but it's not a prohibitive cost.

One way to write out that call:

if( auto stream = ifstream( filepath ); not stream.fail() )
{
//...
}

Well, that's C++17 syntax that may not be available in every corporate
setting. But.

Another way:

do {
auto stream = ifstream( filepath );
if( stream.fail() ) { break; }

//...
} while( 0 );

A third way, which I would probably choose:

void do_stuff( const string& filepath )
{
auto stream = ifstream( filepath );
if( stream.fail() ) { return; }

//...
}

//...
do_stuff( filepath );

> if (auto ptr = someWeakPtr.lock()) { // ...

Using a raw or smart pointer as a boolean condition is so common that I
think this one's justified. Unlike with the stream there is no doubt
about what the implicit conversion to bool does. And the work done by
the `if` body is probably not so extensive as with something that
accesses a file, and is probably more tightly coupled to the context.

> Conversion operators in general are not so useful, but sometimes they
> are handy, e.g. for wrapping primitive types like ints for special
> behavior. For example, one might use a simple mod 8 int type for
> considering the possible 8 directions in some 2D pixel level algorithm.
> Instead of declaring a bunch of arithmetic operations on the type one
> can just use int for arithmetic and normalize the result into 0..7 range
> in the ctor:
>
> Direction dir1 = 0; // north
> Direction dir2 = dir1 + 2; // east
> Direction dir3 = dir1 - 2*dir2; // west
>
> With named conversion functions the last line would become too verbose
> for my taste, considering that the low-level algorithm would be littered
> with those conversions:
>
> Direction dir3 = dir1.to_int() - 2*dir2.to_int();

Not sure about this one.

I think when I've done this I've just used `int` directly. :)


Cheers!,

- Alf

[David Brown]

On 18/09/18 17:26, bol...@cylonHQ.com wrote:
> On Tue, 18 Sep 2018 15:29:59 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 18/09/18 15:12, bol...@cylonHQ.com wrote:
>>> I know what it means, but why not grace us with your clearly sage like
>>> wisdom and tell us.
>>
>> You don't need a lot of wisdom here - a "mouth breather" is someone who
>> breaths through their mouths a lot, rather than through their nose.
>
> Noooo! Say it ain't so!! I bow down before your god like intellect in this
> matter!
>
>> There can be many reasons for this, such as simply having a physically
>> narrow air passage in the upper nose (this is an inheritable trait).
>
> Or because a lot of dumb people have a tendency to have their mouth open when
> thinking. Or just when chewing gum.
>

Eh, no.

>> Having narrow nasal air passages, leading to mouth breathing, is a
>
> Yeah, I'm sure its that.

I'm glad you now understand. It really isn't difficult.

>
>> A little googling showed me that some American's think "mouth breathing"
>> is an insult suggesting someone is stupid. It's a bit like calling
>
> Well I'm not american so its somewhat more widespread.

I have no idea where you are from - all I said was that I found some
Americans use the phrase "mouth breather" to mean "stupid person".

It is much like the kind of ignorant, thoughtless and prejudice jokes
and bullying that was common in the schoolyard when I was a kid in the
70's and 80's. I am very glad I have moved on since those days, and as
far as I can see, so have schoolyards. Maybe such progress has not
reached you yet.

>
>> I think Ian is wrong to compare you to Bart. Bart might be stubbornly
>> and wilfully ignorant, but he is not the unpleasant little turd of a
>> human being that you give yourself out to be.
>
> If being an unpleasant turd means I won't roll over and mea culpa for your
> self righteous virtue signalling bullshit then guilty as charged.
>

So if the idiotic name-calling was /not/ your fault, whose was it?

[David Brown]

I think that all boils down to "conversion operators are occasionally,
but not often, useful to me". And I expect that applies to many people,
with the degree of usefulness depending on the sort of class you are
making. "explicit" conversion operators just means you can make them a
little safer and more convenient without going through the hoops of the
"safe boolean idiom".

[bol...@cylonhq.com]

On Tue, 18 Sep 2018 22:03:12 +0200
David Brown <david...@hesbynett.no> wrote:

>On 18/09/18 17:29, bol...@cylonHQ.com wrote:
>>> Polymorphism - function overloading - works on structural typing.
>>> Concepts work on features. There is a /vast/ difference.
>>
>> For your example its same end result. You'll need a better one to convince
>me.
>>
>
>I would never be able to convince you - you have already decided that
>you don't like C++, and in particular you don't like the newer features
>that you don't understand.

You certainly won't convince me if you're unable to provide an example to
back up your assertions which seems to be the case. If this new syntax is
as useful as you claim then this shouldn't be a problem surely.

[bol...@cylonhq.com]

On Wed, 19 Sep 2018 08:56:42 +0200
David Brown <david...@hesbynett.no> wrote:

>On 18/09/18 17:26, bol...@cylonHQ.com wrote:
>> Well I'm not american so its somewhat more widespread.
>
>I have no idea where you are from - all I said was that I found some
>Americans use the phrase "mouth breather" to mean "stupid person".
>
>It is much like the kind of ignorant, thoughtless and prejudice jokes
>and bullying that was common in the schoolyard when I was a kid in the
>70's and 80's. I am very glad I have moved on since those days, and as
>far as I can see, so have schoolyards. Maybe such progress has not
>reached you yet.

If only I had my violin with me....

I bet you were the sort of kid who burst into tears and ran to teacher as
soon as anyone called you a name.

>>> I think Ian is wrong to compare you to Bart. Bart might be stubbornly
>>> and wilfully ignorant, but he is not the unpleasant little turd of a
>>> human being that you give yourself out to be.
>>
>> If being an unpleasant turd means I won't roll over and mea culpa for your
>> self righteous virtue signalling bullshit then guilty as charged.
>>
>
>So if the idiotic name-calling was /not/ your fault, whose was it?

You're assuming I was at fault in the first place. Sometimes insults are
required.

[Ian Collins]

Or my my case, due to spring hay fever :)

--
Ian.

[David Brown]

On 19/09/18 10:58, bol...@cylonHQ.com wrote:
> On Wed, 19 Sep 2018 08:56:42 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 18/09/18 17:26, bol...@cylonHQ.com wrote:
>>> Well I'm not american so its somewhat more widespread.
>>
>> I have no idea where you are from - all I said was that I found some
>> Americans use the phrase "mouth breather" to mean "stupid person".
>>
>> It is much like the kind of ignorant, thoughtless and prejudice jokes
>> and bullying that was common in the schoolyard when I was a kid in the
>> 70's and 80's. I am very glad I have moved on since those days, and as
>> far as I can see, so have schoolyards. Maybe such progress has not
>> reached you yet.
>
> If only I had my violin with me....
>
> I bet you were the sort of kid who burst into tears and ran to teacher as
> soon as anyone called you a name.
>

Oh, I made jokes and laughed as much as anyone. That does not make it a
good thing, and I'm glad my kids are growing up in a world that takes a
different view.

>>>> I think Ian is wrong to compare you to Bart. Bart might be stubbornly
>>>> and wilfully ignorant, but he is not the unpleasant little turd of a
>>>> human being that you give yourself out to be.
>>>
>>> If being an unpleasant turd means I won't roll over and mea culpa for your
>>> self righteous virtue signalling bullshit then guilty as charged.
>>>
>>
>> So if the idiotic name-calling was /not/ your fault, whose was it?
>
> You're assuming I was at fault in the first place. Sometimes insults are
> required.
>

Insults were not required - they were not remotely justified. They are
just unpleasant for everyone. I don't imagine for a minute that Ian
felt hurt by your post - no one takes you seriously. But that does not
mean people are happy to see you souring the atmosphere.

[bol...@cylonhq.com]

On Wed, 19 Sep 2018 12:14:44 +0200

David Brown <david...@hesbynett.no> wrote:
>On 19/09/18 10:58, bol...@cylonHQ.com wrote:
>> On Wed, 19 Sep 2018 08:56:42 +0200
>> David Brown <david...@hesbynett.no> wrote:
>>> On 18/09/18 17:26, bol...@cylonHQ.com wrote:
>>>> Well I'm not american so its somewhat more widespread.
>>>
>>> I have no idea where you are from - all I said was that I found some
>>> Americans use the phrase "mouth breather" to mean "stupid person".
>>>
>>> It is much like the kind of ignorant, thoughtless and prejudice jokes
>>> and bullying that was common in the schoolyard when I was a kid in the
>>> 70's and 80's. I am very glad I have moved on since those days, and as
>>> far as I can see, so have schoolyards. Maybe such progress has not
>>> reached you yet.
>>
>> If only I had my violin with me....
>>
>> I bet you were the sort of kid who burst into tears and ran to teacher as
>> soon as anyone called you a name.
>>
>
>Oh, I made jokes and laughed as much as anyone. That does not make it a
>good thing, and I'm glad my kids are growing up in a world that takes a
>different view.

Yeah, we can all see the success of that with Generation Snowflake and their
safe spaces.

You need a few knocks in life to mentally toughen you up.

>just unpleasant for everyone. I don't imagine for a minute that Ian
>felt hurt by your post - no one takes you seriously. But that does not
>mean people are happy to see you souring the atmosphere.

You the groups white knight then, vanguishing injustice when you see it?
LOL :)

[Neil Cerutti]

On 2018-09-18, bol...@cylonHQ.com <bol...@cylonHQ.com> wrote:

> On Tue, 18 Sep 2018 11:13:48 +0200
> David Brown <david...@hesbynett.no> wrote:
>>Languages used on servers are often PHP, Python, etc. There
>>are good reasons for this - these languages are dynamic,
>>managed languages with good string support and with standard
>>libraries for handling network protocols of all sorts.
>
> And they can be more easily sandboxed and restricted.

I don't know about PHP, but sandboxed, restricted Python doesn't
exist. It might be easier to sandbox than C++ theoretically, but
nevertheless efforts in that direction haven't yet succeeded.

--
Neil Cerutti

[Scott Lurndal]

One can always run it in a container.

[David Brown]

You can run C++ in a container too.

There are several Python implementations. Surely Jython, which is
Python run in a Java VM, is as sandboxed as Java?

[Ian Collins]

Oh no, not another language that eats all the RAM in one's machine...

--
Ian.

[bol...@cylonhq.com]

I find the sudden resurgence in interest in VMs over the last 20 years or so
rather ironic given how a large chunk of the non emebedded computer industry
has settled upon a single CPU architecture from Intel. Yes, API differences
and all that but translation layers are hardly new. I wonder how much of the
worlds electricity generation is wasted on running VMs rather than raw
binaries.

[David Brown]

The current trend is towards JIT compilation - logically, you are
running in a sandboxed VM, but code that requires a lot of processing
time ends up as native. The aim is to get the best of both worlds.

And the electricity wasted on VM's is peanuts compared to the
electricity wasted on bitcoins!

[bol...@cylonhq.com]

The problem with JIT is that there has to be some code running in the VM
timing various parts of the program and that in itself uses CPU cycles not to
mention the actual compilation itself.

The other problem is that you come up against a variation on the halting
problem - ie will this section always be compute bound or is it just a one
off? There's no way of knowing. Compiling it may end up taking longer than just
leaving it if next time it drops straight through.

>And the electricity wasted on VM's is peanuts compared to the
>electricity wasted on bitcoins!

True.

[Ian Collins]

JIT compilation uses some form of hot-spot detection. At least it did
when I listened to Mike Ball from Sun (he who wrote the first Java JIT
compiler) describe it at an ACCU conference 20 odd years ago. Probably
not so good for one shot programs, but worth the effort for sever side
stuff.

--
Ian

[bol...@cylonhq.com]

Yes, server side definately makes more sense. I've not used java for years
but I do remember the occasionally hang as the VM garbage collected and I
imagine JIT has a similar effect. Wonder if they've improved things or much
faster hardware renders it unnoticable now...

[Ian Collins]

Well they have had 20 years :)

--
Ian.

[Bart]

On 20/09/2018 11:07, Ian Collins wrote:

> JIT compilation uses some form of hot-spot detection.  At least it did
> when I listened to Mike Ball from Sun (he who wrote the first Java JIT
> compiler) describe it at an ACCU conference 20 odd years ago.  Probably
> not so good for one shot programs, but worth the effort for sever side
> stuff.

Mike Ball or Mike Pall?

The latter created LuaJIT. It would be a funny coincidence.

--
bart

[Ian Collins]

Mike Ball, he used to post here (or maybe the moderated group) long ago.

--
Ian