C++ - it'll be nice when it's finished

[salem c]

Or will it (be nice, or be finished)?

https://en.wikipedia.org/wiki/C%2B%2B#Standardization
1998 ISO/IEC 14882:1998[23] C++98
2003 ISO/IEC 14882:2003[24] C++03
2011 ISO/IEC 14882:2011[25] C++11, C++0x
2014 ISO/IEC 14882:2014[26] C++14, C++1y
2017 ISO/IEC 14882:2017[9] C++17, C++1z
2020 to be determined C++20,[17] C++2a

3 years seems barely enough time for a compiler to settle down and produce reliable bug-free code.

3 years seems barely enough time to work on a meaningful project and then only use a fraction of the new features added in recent versions.

To claim you know "C++" is to claim what exactly?

[Niccolo]

To claim you know "C++" is to claim what exactly?

Over larger time scales, this happened to most languages from English to math.

In the 18th century the word "privacy" was almost exclusively reserved for that solitude of the bathroom.

Just 200 years prior English was nearly foreign to modern readers.

C++ extensions, like those you've listed, were designed to be incrementally added to programmers' writing. We may regard C++11, for example, as too important to ignore but that didn't invalidate what was known about using C++ in the prior epoch.

What has remained constant from even early versions of the language (my own use dated to the late 80's) is the computer science used to inform what we build.

3 years seems barely enough time to work on a meaningful project and then only use a fraction of the new features added in recent versions.

In a way, this was the intention from before C++98. There have been certain features with huge impact, like templates, but even templates have been argued to be incomplete (by Stroustrup, where he regards concepts as finally completing templates).

I recall when the STL was new, and so new it couldn't be used. Only "large" machines could process the STL. In that era 32 Mbytes of RAM was $2,000 or more. There wasn't enough room for the compiler to function where the STL was used. It didn't help that compiler support left us wanting, but the hardware itself wasn't generally up to the task. Any substantial use of templates, be they "home spun" containers and smart pointers or the STL, all but required us to use explicit template instantiation (to isolate template code to certain translation units) to deal with hardware imposed memory constraints. That technique is all but unused today.

I was privileged to work on an FEA (finite element analysis) product in the 80's. C++ was too new for use at the time. We knew the only machines capable of performing meaningful FEA for engineering were the supercomputers of the era. Even in the 90's it was generally regarded as impossible for workstations based on microprocessors to handle the work in any practical time, even with severe simplification (to the point of failure toward the intended purpose). Today, FEA is a common component of engineering software targeting everything from buildings to engines.

My point here is that the language may be viewed as growing to match the targets we're able to build. Looking back I personally regard FEA software in the 80's exceeded what the languages used could really support well. Capable hardware was available, though rare and exceedingly expensive for the purpose.

This extends to various API's, too. OpenGL is the first commercial 3D graphics API, which became the model used for decades. At the time linear algebra was supported in that API using matrices and vectors, just like was taught in high schools (for some) and undergraduate courses. Quaternions, however, offer some considerable advantages, yet had fallen into disuse after their invention in the mid 19th century. To the mathematicians of the period, quaternion algebra duplicated what was already known to work well using matrices and vectors, so by the early to mid 20th century hardly anyone beyond PhD's even knew quaternions existed (the occasionally curious undergrad notwithstanding). Quaternions were nearly that kind of relic of history like the early notation of the Calculus used by Newton (we would hardly recognize his 'system').

I don't recall if there was an exact moment, but somewhere along the line some engineer, probably trying to overcome gimbal lock or just looking for a more efficient alternative to matrix by vector multiplication, brought quaternions out of history and into modern re-use (for only part of their original intended purpose).

These changes, from hardware to math, are at least as disorienting and ultimately as advantageous as advances in the C++ language. At least the language advancements are intended for gradual incorporation into our writing.

Many of those advancements are aimed at reducing bugs. While important, those aren't transformational. Using a more modern "for" loop on a container works slightly better than the old fashioned version from C, but it hardly changes what we're making. I'd argue that smart pointers have been transformational and indespensable, but few individual changes fundamentally transform what we build. Taken together, several of these relatively minor extensions of the language may well be regarded as enabling the construction of ever increasingly ambitious targets, but few targets are more ambitious than an operating system and they are largely built in C.

3 years seems barely enough time for a compiler to settle down and produce reliable bug-free code.

I regard this as a cautionary lesson in life about insisting on the newest features as they become available. As it was with the introduction of templates, where they were impractical compared to their modern usage, or the early adoption of auto_ptr (now deprecated and almost forgotten), the gradual adoption of features that mature is quite sufficient for the engineering we do.

One might easily extend your closing question to ask what is it to claim to know programming. To me, C# is still a recent language, and D, Rust, Ruby, Python - all but irrelevant new languages I have little to no interest in using.

One thing I don't witness in the evolution of C++ is the phenomenon of fads, which is how I regard some emergent languages (Rust, for example). Auto_ptr is one of a very few examples of C++ advancements we've left behind.

[Cubbi]

C++ - it'll be nice when it's finished

In software engineering, "finished" means "dead". FoxPro is finished.

3 years seems barely enough time to work on a meaningful project and then only use a fraction of the new features added in recent versions.

If you think three years is barely enough time, how about two months?

Linux_5.2 Released Sun, 7 July 2019
Linux_5.1 Released Sun, 5 May 2019
Linux_5.0 Released Sun, 3 March 2019
Linux_4.20 Released 23 December, 2018
Linux_4.19 Released 22 October, 2018
Linux_4.18 Released 12 August, 2018
Linux_4.17 Released 3 Jun, 2018
...