
Why the C++ standard ships every three years - frostmatthew
https://herbsutter.com/2019/07/13/draft-faq-why-does-the-c-standard-ship-every-three-years/
======
Rexxar
The 1998-2011 gap has made a lot of damage to c++ in term of "market share". I
think it's necessary to avoid something similar happen again.

~~~
asveikau
I kind of see it differently, that the 98 and 03 standards had a lot of
mileage and as necessary as the more recent changes may have been, people felt
the old standard pretty usable for a long time.

C++11 was a really big shakeup. In contrast, C11 isn't a major difference over
C99. Sometimes I read about the rapidly evolving modern C++ and I wonder if
they are moving too fast, as large chunks of the community have not even
caught up with what is already there.

~~~
fredophile
I think it's worth noting that up until 2010 C++11 was known as C++0x.
Everyone knew it was coming. You could get a good idea of what it was going to
contain by looking at things like Boost. C++03 wasn't some abnormally stable
version, it just took a longer than expected time to write the standard for
C++11.

~~~
asveikau
Yes I remember. Also, by the time c++0x seemed "right around the corner" for
several years, a lot of the library features like smart pointers were already
common practice, the standard just, well, standardized them.

It was possible and common to have pretty "modern" styles in c++03, you'd just
have to do without lamdbas etc. and be using less of the 'std' namespace.

~~~
humanrebar
Strong disagree.

The nonsense needed for "variadic" templates in C++03 isn't "just do without
lambdas". You basically have to walk on eggshells to get the equivalent of
unique_ptr. Not having to type std::vector<SomeTypeName,
WhateverBuffer>::const_iterator changes the way you write code, too.

The stronger guarantees on copy elision lets you skip return by reference
nonsense more aggressively.

------
cousin_it
This sounds like a great idea, can't believe I didn't see it earlier. Maybe I
should adopt it for my personal projects (software, music, etc): pick a
regular release schedule and stick to it, even if it means releasing less
feature-rich stuff. Does anyone have experience with this approach?

~~~
skummetmaelk
This is sort of what scrum does isn't it? Release every cycle no matter what
was completed. Whatever was not completed goes back into the backlog and
potentially into the next cycle.

~~~
saagarjha
> Release every cycle no matter what was completed.

What happens when your software is in a broken state that's worse than what
you had before?

~~~
justinator
I guess the keyword is, "completed". If something is broken, I doubt it would
be in master, or the team has done something terribly strange. Or they should
be nicer to QA ;)

------
freyr
Considering that C++ has evolved a lot over the years (and grown quite large),
what are good resources for a programmer to get started with the language in
2019?

I've heard Accelerated C++ is a good introduction, but it's quite old at this
point. Would Accelerated C++ followed by Effective Modern C++ bring someone up
to speed with modern C++? Is there a single book or online resource that would
service this purpose better?

~~~
Bekwnn
I'll second Scott Meyers and add that Essential C++ covers the most
fundamental parts of the language. Books beyond that tend to cover much more
specific and optional tools.

Reading Essential C++ cover-to-cover was very worthwhile in my job as a
programmer in AAA games. Books beyond that have mostly involved thumbing
around different items to see which I might find useful at some point. Games
in particular tend to be very performance sensitive, but also compile-time and
debug-performance-sensitive. A lot of the STL is not as respectful of those
latter two, meaning a lot of game code uses little or even none of the STL.
(Working with UE4 will involve using none, for example.) I'd definitely focus
more attention on understanding core language features that the huge amount of
content that exists in the STL.

By far the best element of C++ that a lot of other languages lack is const and
const-correctness. The second best would be the robust features templates have
in comparison to generics of other languages (though the applications allowed
by that robustness can be mildly horrifying at times).

~~~
pkolaczk
Const correctness in C++ is a nice feature, but to say it is missing in many
other languages is a bit exaggeration. Many other languages offer a much
superior tool - immutable data types. Immutability is stronger than C++ const
correctness and easier to use at the same time.

Templates are nowhere near capabilities and ease of use of languages with
proper (read: not accidental) macro/metaprogramming systems (e.g. Lisps) or
languages with modern generic type systems designed from the ground up
(Haskell, Scala/Dotty, Idris, etc). Templates are IMHO a powerful hack, but
hack is still a hack with all the consequences - terrible error messages, slow
compile times, difficult debugging, late error detection, a lot of accidental
complexity caused by templates not being first-class citizens etc.

~~~
edflsafoiewq
> Immutability is stronger than C++ const correctness and easier to use at the
> same time.

C++-style const appears to be stronger than just immutability, since you can
have immutable objects in C++, but you can also pass const references to
mutable objects.

~~~
barrkel
Precisely why it's harder to use. C++ is more expressive, and thus creating
self-consistent designs is harder.

~~~
pkolaczk
C++ is more expressive than what? Than C probably. Than Java/C# - arguable.
Than Scala/Haskell/Rust/Python/Ruby/R - no way.

~~~
barrkel
More expressive than Java, sure. Java doesn't have overloaded operators, or
cv-qualifiers, or templates, or many many many other things that make the type
design space more expressive.

Ruby is hardly expressive at all in this respect - you can express to the
interpreter very little about types, and the interpreter won't help you much
at all.

~~~
pkolaczk
C++ doesn't have GC, reflection, annotations, code generation utilities
(annotation processors, cglib, etc), first-class generic types, existential
types, rich standard library etc. That's why it is "arguable".

> you can express to the interpreter very little about types

Dynamic types are still types. Only the error detection moment is different,
but lack of static types doesn't mean low expressivity.

------
corysama
I’m sure the committee has thought about this 1000x as much as me. But, I wish
they would go further and release every year. IMHO, that would relieve most of
the pressure to push out features that aren’t fully baked. 3 more years is a
long time to wait if you’ve already been working on something for several
years. 1 more year, when you know you could use “maybe a couple more months”
(likely 8 in practice), not so bad.

~~~
dwaite
The final review process (for ISO standards) is most probably the bottleneck
there.

~~~
motajaxxer
ISO generally allows only 5 year cycle. 3 years for C++ is a special case.
Furthermore, the bureaucratic overhead will dominate the proceedings then (not
unlike thread thrashing).

------
steveklabnik
I’m a huge fan of this strategy; we use it with Rust, for virtually identical
reasons. Ruby also ships each Christmas.

~~~
mehrdadn
Can't speak for Rust, and I imagine it makes more sense for them since it's a
young language, but I wish the C++ folks would chill a bit and take their time
a little more; it's getting kind of ridiculous. They don't need to move fast
and break things (which they literally have; see e.g. result_of and
invoke_result). By the time the tooling across various platforms has finally
had a chance to take a breath, they've already got the next version of the
standard out, and it's getting hard to keep up with all their changes. I feel
there's a better balance between the 13 years ('98->'11; '03 wasn't really a
new standard) and the 3 years we have now. Maybe every 5-6 years?

~~~
steveklabnik
I don’t think that making the cycle time longer helps; I think making it
shorter helps. There’s less pressure to put something in a specific release
when they happen less frequently. You can, counter-intuitively, take your
time.

I know less about the exact details, but I also think that having something to
play with helps; I believe that this is what’s going on with with the move
towards more TSes before shipping spec text, right? Being able to try things
out in nightly helps us a lot.

~~~
mehrdadn
If your goal is to help improve C++, sure, a shorter cycle time is better. If
your goal is to use the language as a communication mechanism... having it
change constantly underneath you isn't helpful in my experience. And it's not
necessary to release a new standard to let people try things out; you can let
people play around with new features without iterating on them as formal
standards.

~~~
steveklabnik
“Change constantly” is too broad; there are different kinds of changes.
Stability is paramount.

~~~
mehrdadn
If you find it too broad then just narrow it down in your mind. You won't be
left with the null set.

------
nayuki
This is similar to Java's transition from a feature-based release model to a
time-based release model. The first rapid release was Java 10 in March 2018.

------
hellofunk
So, in 2019, if you want the execution speed and efficiency of C++, high level
features, without the complexity of C++ or rust, how about Nim??

~~~
vips7L
Isn't nim garbage collected? The better alternative is probably Zig.

------
carlsborg
C++ needs to merge with Python to create the uber-language: Python for rapid
development, and drop to C++ for performance. Like Cython, but with native
integration.

~~~
readams
What stops you from doing this now? This is pretty much how Python works
currently when you need performance.

~~~
carlsborg
For the most part, today's solutions let you write python modules in C/C++. So
your core app is in python. I am thinking of the scenario where your core is
in C++ and extendable in python for the business logic -- where the core can
be a trading system engine, or a webserver for example. The rationale is
python serves the algos/data scientists/quants use case really well, and C++
does the "engine" part of things really well.

------
abductee_hg
as long as basic things like __alignment__ are still fundamentally broken I
simply do not care about the syntax. (I mean it doesn't get anything more
basic than this, no?)

~~~
edflsafoiewq
What's wrong with alignment?

~~~
abductee_hg
well there is this: #ifdef _MSC_VER __declspec( align(16) ) struct float4 {
float v[4]; }; #else struct float4 { float v[4]; } __attribute__
((aligned(16))); #endif

but the main problem ist tthat alignment is _not_ part of the typing system. (
alignas vs alignof )

butt, to put it more general: 90% of your performance is in memory access and
compilers are rubbish optimizing those, they are however getting increasingly
good at the 10%. see also
[https://www.youtube.com/watch?v=rX0ItVEVjHc](https://www.youtube.com/watch?v=rX0ItVEVjHc)
for realworld examples/exploration

~~~
account42
> well there is this: #ifdef _MSC_VER __declspec( align(16) ) struct float4 {
> float v[4]; }; #else struct float4 { float v[4]; } __attribute__
> ((aligned(16))); #endif

I don't understand what you are trying to say here? Why not just use

    
    
        struct alignas(16) float4 { float v[4]; };
    

You can even put both __declspec( align(16) ) and __attribute__
((aligned(16))) in the same place if you want to have a fallback for older
compilers.

------
NTDF9
Glad to have left C++ behind. I thank it for making me a better software
engineer but I don't think I want to work with core dumps for the rest of my
life.

~~~
hawski
Are core dumps per se, really bad? I think, that the feature is useful. What
is bad is frequency of it happening. For example: are Python's tracebacks
better? Maybe I had a bad luck, but in my experience they happen with similar
frequency. Core dumps allow you to go to debugger and see what has happened.
You can easily send the file. If the crashed software goes without source you
can't do a thing, but that's what was the intention. With obfuscated Python
one would also be left with nothing.

~~~
module0000
I speculate the parent comment was referring to the frequency of core dumps:
that he/she experiences more of them compared to the Python tracebacks you
mentioned.

Disclaimer, I'm _speculating_ that's what they meant, because I feel the same
way. It's more common(for me) for Python to refuse to run than to run anyway
and later crash, compared to C++. That said, Python isn't a good analogy
there...Rust or Golang are more likely to refuse to run for bad code instead
of running anyway and crashing later.

