I've only really ever made one project in C++, and I spent a good deal of time learning the "right way" to make different kinds of constructors. And all I could think is, if there is a "right way" to do it, then why isn't it the default? Why am I actually doing research on how to write boilerplate?
It's because C++ is a disaster.
Everyone likes to point out that you should only use a subset of the language. But that's not my experience with C++; only using a subset makes you vulnerable to all the problems associated with not understanding the actual language that is implemented, not just the subset you wanted it to be.
This is not completely false, but clearly the view of someone who does not understand C++.
Yes C++ carries decades of history, but since C++11 even if you can still make use of this you don't have to cope with. It is perfectly fine to use only a subset of C++, you just have to use the right one and this is what this documentation is about IMO.
Yes you have to understand the language to be efficient with it, but it is a language that allows high performance and maintainable large scale software.
Python was cited as an example in this thread and I don't get it. There a many ways to write the same thing in Python and I always end up spending more time looking on the web to figure out what is the "Pythonic" way.
The difference is that not being "Pythonic" is a style issue. A Python guru may scoff and point out that you could write the same thing more elegantly some other way, but most of the time the performance is the same, and the behavior is correct either way.
On the other hand, not following some of these C++ guidelines can mean your code is subtley broken and depending on undefined behavior, or leaking memory, or accessing something it shouldn't, etc.
I write C++ at work. We all know the language pretty well. We send people to conferences. We have somebody presenting at CppCon next week. We still get bitten by C++ more than you would belive.
You are comparing apples and oranges here. Please compare C++ to other systems languages that are regularly used to write systems / fast / "unsafe" code.
I'm sorry, but I'm not the one who brought up Python.
In any case, even compared to other systems languages, C++ is a mine field. It's sad that C++ and C are so entrenched that you've even equated systems and fast and unsafe, when unsafe really doesn't belong there.
Look at Ada. It performs just as well as C++ and is/was routinely used in low level embedded systems and safety critical systems. It's widely regarded as safe and doesn't have the problems C++ is so often associated with. It was first standardized in 1983 and C++ is just now getting around to adding some of the stuff Ada has had all along.
And then there are the newer, relatively unproven languages like Rust, Go, and D.
I'm pretty good with C, and while C has some safety issues, it doesn't usually bury them under miles of encapsulation. It's also a small, tight language that isn't trying to reinvent its syntax every 5 years.
And there's Rust: it's a pleasure to work with and has almost none of C++'s problems.
Oh, but C++ is so much fun for interviews - who can forget the joy of endless trick questions about code that looks like it should do one thing, but actually does another.
Oh man, I miss those days, ha ha.
You know you've finally reached peak C++ post-traumatic stress disorder when you walk into an interview and someone says "what does 'int x=5;' do?" and you spend half an hour trying to figure out what manner of hideous deception lies behind that simple expression. Your brow starts to sweat, your hands shake, and finally you exclaim "Undefined!".
>But that's not my experience with C++; only using a subset makes you vulnerable to all the problems associated with not understanding the actual language that is implemented, not just the subset you wanted it to be.
The real problem is your simple subset is often built with the very difficult features your attempting to avoid using. So by running from complexity you just embrace it, but don't learn that you're actually working with virtual templated necromancy until 2-3 months later when you try to extent the production code base.
I think one of the problems is that for any project that is moderately complex you really need (or at least would greatly benefit from it) to master the language + companion library Boost.
I did two relatively big projects (years apart), with the last one using Qt (because I also needed to do a GUI), and despite it working and doing what was supposed to, I wasn't entirely happy with the quality of the code.
It's because C++ is a disaster.
Everyone likes to point out that you should only use a subset of the language. But that's not my experience with C++; only using a subset makes you vulnerable to all the problems associated with not understanding the actual language that is implemented, not just the subset you wanted it to be.