Pass by reference was a mistake. Doesn’t need to exist. Obscures what’s actually happening at the call site. Overloads the minds of programmers with an unnecessary third option, which causes bugs like this. Some other non-null indicating syntax for pass by pointer (visible at call site) would’ve made more sense.
I feel exactly like the author. I get less comfortable with C++ year after year, despite writing it all day. I feel like a race car driver who was once confident but has now gotten into too many big crashes.
I feel similarly, but come at it from a different angle. I first learned C++ in undergrad ca. 25 years ago. I never used C++ much professionally, going first to Java, then Python, and then C. About two years ago I started doing more work in modern C++, and after the initial shock of “this isn’t the same language I learned years ago”, I’m constantly terrified at the growing complexity of C++. I’m glad to hear people with unbroken C++ experience admit that they don’t think anyone understands this thing well.
"the third option", what's the first two, pointers, then what?
I'm re-entering c++, I wonder, can we just use a small subset of it and get the job done? it seems a core subset can get a lot done without all the complexities from c++
The first two of these are weird cases for reading the standard and arguing with your compiler vendor because regardless of the legality they’re stupid code. Reference lifetime extension is useful for generic code where the function may return either a reference or a value, and is just bad code in nearly any other circumstance. The array initialization example is something that never actually worked, and a newer compiler version exposing some code that appeared to work but didn’t is sort of routine?
1. Vendor lock in on platforms is still there and is not going anywhere.
2. Existing code. Every successful AAA project / game engine has a mountain of code that is already there. Often with even bigger mountain of data that no one really wants to redo. It also often depends on multiple middleware or open source packages that already work and are hard to replace.
There is no rational reason to keep learning historical accidents why things are like they are in C++ but see points 1 and 2 above.
> I am hoping there can be a cleaner successor language that lets you easily use C++ code when you need to but also allows you to ignore the C++ complexity when you aren’t touching the C++ code directly.
I do not understand how left hand of author wants to run C++ code with all of the data going in and right hand does not want to touch it. It does not work like this. At least in gamedev. End of rant.
Specifically,
- incompatibility with C is just stupid
- agreeing with sibling comment, references were a mistake
- the complexity has really gotten out of hand.