
C++17 is formally approved - ingve
https://herbsutter.com/2017/09/06/c17-is-formally-approved/
======
everheardofc
C++ shows that in theory you can fix any flaw in an existing programming
language as long as you maintain backwards compatibility by simply adding more
features. The only thing you cannot change are implicit defaults (e.g. pass by
value is the default, you have to manually opt out to pointers or references).

I like modern C++ because for me it's a reasonable compromise between java
safety and C safety. Other than out of bounds memory accesses and legacy code
I feel there is not much that can go wrong. However compiling C++ projects
takes ages and in the projects I've worked on I often have to modify headers
that are included almost everywhere. Every trivial changes requires a 5 minute
rebuild.

After working with several high level programming languages with slow
compilers I realised the following: typing is fast, compiling is slow. There
is a reason why go is so popular. It offers that tradeoff in fast turn around
time / compilation time with reasonably good performance and simplicity in
exchange for more keyboard bashing and keyboard bashing is a cheap price to
pay for what you're getting back.

~~~
staticassertion
> C++ shows that in theory you can fix any flaw in an existing programming
> language as long as you maintain backwards compatibility by simply adding
> more features.

I feel like C++ proves exactly that you can't.

~~~
candiodari
If C++ is so bad then why:

1) are 90% every really large software projects written in C++. All the
programs "everybody knows" just happen to be in C++. Examples include Chrome,
Windows, Microsoft Office, Adobe tools, KDE, Autodesk, ...

Clearly those programs have massive scopes, large complexity, the need for
extensive abstractions, the need for large teams cooperating, tests, ... all
the stuff we value as programmers.

2) Are all programs in most other languages so ... small. In scope, in
features, in ... Just look at Go programs on github. Or python ones.

Very large Python projects are a few 10's of thousands of lines of code. And
they are limited by their complexity. Somehow C++ programs seem to have less
of this problem.

Very large javascript projects don't even seem to get above a few thousand
lines of code. And reading them, I can see why. Typescript at least seems to
match Python in how much complexity it can contain without imposing too much
of a burden, but that language doesn't match C++ either.

Most of those fancy languages are artificially limited in some ways. For
instance, you cannot easily link QT into Go (nor can you do that with many
other libraries, GTK has the same problem). C++ does not have that problem,
and if it does, you can solve it. I do not claim doing so is easy, but it can
be done. You're not stuck. Go on IOS ? It sort of works, with a boatload of
limitations that make it utterly unworkable. C++ on IOS ? It works, with less
limitations than Objective C.

I feel like C++ gets a much worse reputation than it deserves. Much worse. It
is not the solution to everything, of course.

~~~
sgift
1) I know so many programs which are the same size or bigger than your "well-
known" programs you probably never heard of but still use daily - They are
just not desktop programs, a place where C++, for various reasons, is often
the language of choice, but desktop programs are (for better or worse) just a
small subset of all programs written.

2) See answer above.

> I feel like C++ gets a much worse reputation than it deserves. Much worse.
> It is not the solution to everything, of course.

In the end it all boils down to Stroustrups quote about programming languages:
'There are only two kinds of languages: the ones people complain about and the
ones nobody uses'

------
humanrebar
Here's a good rundown of all the changes in C++17:

[https://stackoverflow.com/questions/38060436/what-are-the-
ne...](https://stackoverflow.com/questions/38060436/what-are-the-new-features-
in-c17/38060437#38060437)

~~~
sddfd
You may want to change the link to

[https://stackoverflow.com/questions/38060436/what-are-the-
ne...](https://stackoverflow.com/questions/38060436/what-are-the-new-features-
in-c17/38060437#38060437)

~~~
humanrebar
Done. Thanks!

------
doldge
So I'd like to learn more about modern C++ and how to write it, but I'm not
really sure where to begin. I've tried a couple of times, but coming from a C
background, my code tends towards C styling with only the occasional use of
C++ features.

Is anyone aware of a good tutorial or reference list for writing good modern
C++ (C++11 or newer, I guess)?

~~~
Veratyr
As a newcomer to C++ myself, I found Stanley Lippman's C++ primer to be
helpful. The latest edition includes the newer features.

And in case it helps, the main things I find myself using differently to C
are:

\- Smart pointers. If you're not using them, use them. They're amazing.
Seriously. Never have to worry about freeing something ever again.

\- Object oriented design.

\- Const reference arguments.

\- The occasional auto.

~~~
ChrisSD
I'd second _C++ Primer_. It's a great overview of the language and has been
updated for C++11. Unfortunately it was written too early for C++14 and beyond
so if there is a newer edition planned (I've no idea) it might be worth the
waiting. In any case C++11 was the big change for C++ so the fifth edition is
still worth while.

One word of warning though, there's a confusing similarly titled book called
"C++ Primer Plus" which you should avoid at all costs.

------
kensai
It's very nice to hear progress on the C++ all the time. On the other hand, I
cannot find any news on the C2x progress, as if C did not evolve.

------
rb808
So I used C++ a long time ago but moved to Java/dotnet/python platforms. I do
miss some low level stuff but not random crashes.

Is there a reason to use C++ any more? Has anyone gone back and had good
experience? I'd kinda like to but am wary of the old problems. (The other
problem is that most interesting business logic is no longer in C++.)

~~~
futurix
If you had 'random crashes', you probably weren't that good with C++ ...

~~~
andreasgonewild
It's definitely getting easier, but I still wouldn't even consider C++ without
valgrind or similar watching over my back; and I've been writing C++ since
1995. Accessing a variant value as the wrong type, dereferencing empty smart
pointers and accessing non-existing elements in collections and many many more
cases will still segfault; and I don't expect that to change since it lacks
that level of security by design. That being said, it's still the most
pragmatic language around; the only language that allows me to choose my own
level of crazy.

~~~
futurix
Exactly! C++ is a language where you are free to choose level of safety.

None of your examples are a fault of the language - it is a fault of developer
not doing necessary safety checks.

~~~
johannes1234321
The point is: some languages have capabilities to take some classes of errors
out. A language with GC and heap-allocation only makes it hard to get access-
after-free-style errors. Languages with bounds checks on all elements reliably
crash (throw an exception) instead of showing "random" behaviour on bad reads.
Of course all of that comes with a cost, but for many domains that works out
...

------
tcbawo
Scanning through the list of features, one I dislike is selection statement
initializers:

if (init; condition) {}

(Ref: [http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2016/p030...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r1.html)). It just seems like
clutter. I generally prefer when languages discourage side effects in a branch
condition.

~~~
jacobparker
That's sorta the point... the init isn't the branch condition. It gives terser
syntax to a common patter where you want to scope something into the body of
an if statement.

    
    
      {
        std::unique_ptr<T> x = foo();
        if(x->something()) {
          // use x
        }
      }
      // x out of scope, destructed
    

becomes

    
    
      if(auto x = foo(); x->something()) {
        // use x
      }
      // x out of scope, destructed
    

It's makes it easier to read the lifetime of x (an important thing you have to
manually keep an eye on in C++ in many cases), and to determine what is in
scope outside of the if statement. It's analogous to for-loops vs. doing loops
"manually" with while. You're just used to for-loops by this point (if you
don't like for loops then ok :).)

C# is also getting (has got?) this feature.

~~~
tcbawo
If I'm reading the paper right, the init statement could be any expression-
statement or simple initialization. So, modifying unrelated, externally scoped
variables in the init would be legal. I don't see this improving readability.

~~~
rleigh
It's no different than the init and conditional parts of a for loop. Do people
abuse for loops to do unrelated tasks? Not really.

It does improve readability. If you've ever had to have a series of
conditionals in their own braces to keep the init variable in its own scope,
then you have a use for this. The alternative might be having foo1, foo2,
foo3… all in the same scope, and it's too easy to use the wrong one. This
keeps things specifically constrained to the scope in which they are used,
which improves safety and correctness, and I think also readability once you
adapt to it.

Yes, it could be abused, but I don't think that's a reason not to use it for
its intended purpose.

~~~
tcbawo
People mess up for loops a lot! That's why range-based for and the STL
algorithms library are so useful. I agree having multiple fooX variables in
scope is bad. In practice, I've found that either many of these return types
are identical, so variables could be reused, or the logic flow could be
organized in a more straightforward way.

~~~
rleigh
I wouldn't want to reuse a variable for multiple purposes though; that can
lead to unintentional use of the wrong value. At least this way you ensure
that can't happen.

And agreed that people mess for loops up, and range based loops are better. My
point was only related to the syntactic precedent for coupling an initialiser
and conditional in a statement.

~~~
tcbawo
Generally, variable reuse is bad. But for something like an error flag that
immediately causes function exit and is never referenced again, I wouldn't
raise an objection in a code review.

------
gumby
I really hope I can soon replace

    
    
      add_compile_options($<$<COMPILE_LANGUAGE:CXX>:-std=c++1z>)
    

with

    
    
      set (CMAKE_CXX_STANDARD 17)
    

Note: we had a green field application that started with an empty Emacs buffer
so figured we could go straight to C++17. I doubt this is a particularly
common case right now.

~~~
rleigh
Supported since CMake 3.8!

~~~
gumby
Yeah, CMake supports it and G++ accepts it but Clang++ doesn't yet, and we
compile with both compilers.

Edit: and LLVM 5.0 was released today; clang now accepts the flag!

------
zelos
There are some nice things in there, but the destructuring looks a bit odd:

    
    
      struct S { int x1 : 2; volatile double y1; };
      S f();
      const auto [ x, y ] = f();
    

So it's just ordering based, I can't pull out one member by name?

~~~
21
It's yet another feature stolen from Python.

Next version maybe they will even allow stuff like

    
    
      [x, [y, z]] = f()
    

or

    
    
      [x, y, z...] = f()

~~~
ska
These ideas are a lot older than python, about as old as multiple return
values.

------
copx
Does anyone know the status of UFCS?

I know it's not in C++17, will it be in C++20?

------
ericfrederich
Does it have coroutines? Python has had them since 2.5 (2005) and Golang has
obviously had them since the beginning.

When will C++ finally catch up?

~~~
pjmlp
When will Python finally get rid of the GIL and offer AOT compilation to
native code?

~~~
jacobush
To be fair, none of these would be part of a language specification, only a
specific implementation.

~~~
gcp
Something something "export" for templates cough gargle

~~~
jacobush
Gesundheit!

