I’ve been programming in C++ for almost a quarter of a century now. I grew up, professionally, with C++, and in many ways, it grew up along with me.<\/p>\n\n\n\n
For someone who is used to C++, even used to recently-standardised C++, it’s hard not to feel apprehension when looking at C++20. Modules, coroutines, ranges, concepts — these are all massive features that I don’t have real experience with yet and that offer completely new ways of doing things. There are also several medium-sized features which could turn out to have large impacts; for example the spaceship operator, or the further expansion of It’s very easy to react to all this by thinking, “It’s too much; it’s not baked yet; C++ is collapsing under its own weight.” And it’s natural not to trust something new, especially when I already know how to solve my current problems using current technology.<\/p>\n\n\n\n What I try to remember is: this isn’t a new situation, and this isn’t a new feeling<\/em>. It’s not new to me, and it’s not new to the world. Many people have felt this way about different technologies over the decades, and very seldom has actual catastrophe been the result.<\/p>\n\n\n\n We felt this way about C, when we programmed games mostly in assembler. We felt this way about object-oriented C++ once we started trusting C. We felt this way about generic C++ and the STL after we’d gotten used to object-oriented C++. Some of us currently feel this way about C++11 and beyond.<\/p>\n\n\n\n Often this feeling is based on seeing new tech not (currently) performing quite as well as old tech for certain use cases. This is also not a new concern. People even thought the same about assembly language, preferring actual machine code! In her HOPL keynote (1978), Grace Hopper said:<\/p>\n\n\n\n In the early years of programming languages, the most frequent phrase we heard was that the only way to program a computer was in octal. […] the entire establishment was firmly convinced that the only way to write an efficient program was in octal.<\/p><\/blockquote>\n\n\n\n It’s not wrong to feel this way because feelings aren’t wrong. But it’s also worth remembering that we’re always<\/em> on the edge of technology that is in the process of proving — and improving — itself. Some things don’t stick around, but many do, and they get better, usually surpassing older tech in all sorts of ways, performance included.<\/p>\n\n\n\n We’re always learning how to do more. Betting against progress is seldom a good bet.<\/p>\n\n\n\nconstexpr<\/code> capabilities.<\/p>\n\n\n\n