
C++17 Is Here: Interview with Herb Sutter - AndreyKarpov
https://www.infoq.com/news/2017/10/cpp-17-herb-sutter-interview
======
turbinerneiter
Being new to C++, on of my biggest gripes is that I often feel unsure whether
I'm using the right way to do things, or if I'm using an old method that was
replaced by a new one. Especially given that I never took the time to properly
learn the language, but mostly piece together SO answers ... .

Is there a C++17-exclusive compiler-flag? Or linters that inform you about
outdated concepts? Some way to get rid of the backwards compatible cruft when
writing new things.

~~~
GuB-42
My opinion is that there is no "right way" of doing C++, unlike, say, python.

You can write a kernel in C++, or you can do high level UI, or a game engine,
and these will be very different, you can almost say you are using a different
language.

For example, to allocate an array, you can use a vector, array, new, or
malloc. Most people will tell you to use a vector, but a vector uses a bit
more memory than an array, so you might want to use this instead, but you may
not want to link with the STL at all, so you go with new, but if you don't
want to deal with exceptions or just want a block of raw memory, you may want
to go with malloc instead.

Just use the new features if it makes life easier for you, that's the idea. As
for linters, I know that cppcheck can warn you of C-isms (ex : C-style casts)
but I don't know any of them that target modern C++ variants.

~~~
kllrnohj
> My opinion is that there is no "right way" of doing C++, unlike, say,
> python.

There are, however, definitely wrong ways of doing things in C++. There's
quite a few things in the STL that should have long since been deprecated if
not outright removed.

Simple example is std::map. Absolutely horrible data structure.
std::unordered_map is what you actually want, but to a beginner nothing really
tells you that. You just think "I need a map, oh hey there's a std::map,
perfect!" and go about your day completely unaware of how awful a data
structure you just chose.

Another example that's a mistake made in C++ hello worlds of all things is
std::endl. std::endl does not mean "end line", it means "\n + flush"
(specifically '\n' \- it does not do '\n\r' or '\r\n' conversions at all, the
underlying file system does that). And flushing on every new line only makes
sense for line-buffered things like std::out, but std::out already flushes on
'\n' character. So std::endl in practice just leads to a ton of unnecessary &
unexpected flushes.

> so you go with new, but if you don't want to deal with exceptions or just
> want a block of raw memory, you may want to go with malloc instead.

There's actually very little reason to ever use malloc. If you globally don't
want exceptions just use -fno-exceptions. If you don't want exceptions in the
small scope you're working in then use std::nothrow, eg: "new (std::nothrow)
int[1024 * 1024]".

As for why you do this over malloc the reason is simple - it avoids overflow
bugs. new int[size_t] never overflows. malloc(size_t * sizeof(int)) - well
that overflows trivially, and that overflow results in security bugs.

Raw malloc would arguably be another case of "this is just wrong C++" rather
than "this is a perfectly valid alternative". Raw free would belong in this
case except for calloc, which is still very useful (and avoids the common
overflow bug that malloc has). malloc's only saving grace is realloc, but now
you're pretty deep into a specific edge case.

~~~
je42
actually, you should see the pain that you get when having unordered
dictionaries by default.

which is the default in python, you get awesome effects, where the order of
the unordered dictionary is dependent on the random seed.

where library implementor are serializing a dict into a serial structure (and
are not sorting by key). running the same code and same data twice, will get
you potentially different results.

now here comes the best. most of the time in python you don't see the
difference. the output is exactly the same but never the less the order is not
guaranteed.

so I believe having an ordered by default data-store will help the ecosystem.

Calling it unordered explicitly helps, to make sure that anybody serializing
the structure will need to make a choice how to sort it.

~~~
jnwatson
In Python 3.6, dicts are now ordered.

~~~
je42
it's an implementation detail. not guaranteed. :( which makes this even worse.

------
jerrre
Not directly related, but a question that popped up while reading this:

As a C++ programmer I'm quite happy to see the language keep improving in
quite a good pace, but I'm wondering if anyone can shine some light on how
this evolution compares with other widely used languages.

Of course newer languages can change drastically quite fast (Swift comes to
mind), but I don't follow more accomplished languages (PHP, Java, JavaScript,
Python, Even C, ..., sorry if I didn't name your language) close enough to get
an idea.

~~~
dtech
That's quite a list of languages. Here's my opinion on a few that I know:

My impression of C++ is that is evolves fairly quickly, but also includes
everything, the kitchen sink and the highway, making for an expansive and
complex language. Scala gets some of the same flak.

Java evolves glacially, and outside of very rare large improvements (e.g.
lambda's in 8) it's still the same (verbose) language and will remain for a
long time.

PHP evolves fairly quikly, but the API's aren't consistent leading to a bit of
the "flavor of the week" feeling for new additions. I don't know how this has
been since PHP 7+

Javascript is evolving at a rapid pace, but despite that they seem to move
toward a clear goal with nice functional API's and constructs being added to
the language.

~~~
FranOntanaya
PHP 7+ hasn't added that much in terms of new APIs — (e.g. libsodium in 7.2,
and it's typical function(target, arguments) stuff). It added strict typing
and a very significant bunch of ergonomic/performance changes.

I'd say half the reason to call it a quick evolution is how fast it's being
adopted compared with the glacial progress from 5.2 to 5.6, or Python 2 to 3.

Also a third half of the freshness has been adoption of packaging and coding
standards.

------
jokoon
Sorry but I am going to complain again about modules. I mean I'm inches from
making a petition so that compiler vendors can agree on something and move on.
This would make the language much more attractive for new users, reduce
compile time, etc.

Please!

~~~
maccard
What good does a petition do for this. If you want them so badly, why not use
them, and give feedback to the vendors about what approach they should
standardise on?

~~~
jokoon
What must one do to test them?

Are there beta version of compilers, would it be GCC, clang, MSVC?

------
pducks32
I do really love how C++ is evolving. The language is fighting and adapting
and I think in a very smart way. This old dog can learn new tricks. I also
love how often it makes me feel stupid at the incredible knowledge of it's
maintainers and implementers.

------
devrandomguy
Wow, just thinking about C++ while slacking, was enough to inspire a solution
to a race condition in my Clojurescript project.

Earlier, I made some notes and walked away from the problem, because it was
getting frustrating. Then, while I was checking this out, I started thinking
"Imagine how complex this would have been if I had done it in C++" Then the
immediately following thought was "Well, in C++, I would instead build it like
so, because it needs to be thread safe." Problem solved, obvious-in-hindsight
solution.

Even though my problem wasn't caused by a low level threading mistake,
thinking about the problem in the context of a more primitive tool helped me
to better understand how my own tools are working.

------
72deluxe
Stroustrup said he was disappointed with C++17 as it didn't introduce anything
massive. You can see him mentioning this widely and openly at cppcon last
year.

It'll be interesting to see what gets in next.

~~~
andrepd
Well concepts and modules, arguably the most important features C++
desperately needs, are still missing from this release.

~~~
fnord123
eh, check that modules is what you think it is/should be:

[https://izzys.casa/posts/millennials-are-killing-the-
modules...](https://izzys.casa/posts/millennials-are-killing-the-modules-
ts.html)

Modules without buy-in from build tools (or a fresh build tool) will probably
be DoA as Isabella says.

~~~
boris
There is a fresh build tool that supports modules in the big three (GCC,
Clang, and VC):

[https://build2.org](https://build2.org)

------
inciampati
Does anyone know the state of modules (so as to support something like npm) in
C++?

~~~
Longhanks
Modules (in the C++ terminology) and a package manager like npm are two
different beasts. Modules are not part of C++17, although Clang and MSVC both
bake their own bread with implementation of the current modules draft.

