Disclaimer: I actually like C++ the language, I'm reasonably comfortable with it and enjoy it as an upgrade from C. I don't use much OOP stuff as I'm writing a game using the flecs ECS. So things like abstract classes are mostly absent from my codebase.
What has been driving me up the wall the last month has been build systems and dependencies: don't get me wrong; meson is great but the problem is not everyone uses meson. All I want to do is add some library built with cmake as a dependency without needing to rewrite the build system or install it on my OS. Apparently that is too much to ask!
I'm seriously considering dropping everything and jumping to Rust because of Cargo. Yes I've tried setting up conan but not having much fun since the packages are all third party and out of date anyways
After you've done some languages, they all look the same. Yes, some have interesting features like the indent-based blocking of Python, and I'll have to look up if the new language has "else if", "elsif", "elif", or whatever, but als long as it is coming from the family of ALGOL-like languages, it does not matter much. You'll learn the basic functions needed to get around, and off you go.
Just a few weeks ago, I started learning Python. Yes, this indenting takes some time to get used to. My son does Python for about a year now - he started with it at university. Maybe ten days after I started learning, I invited him to have a look at my first Python program. I have no idea what he expected. A "Hello, World" with a few extra features, maybe? Definitely not the 2.5k lines app I had written in my spare time, with GUI, databases, harvesting data from a web site with caching, and creating PDF files with optimized layout for the data I processed. In the end, it was just another programming language.
C is dangerous like your uncle who drinks and smokes. Y'wanna make a weedwhacker-powered skateboard? Bitchin'! Nail that fucker on there good, she'll be right. Get a bunch of C folks together and they'll avoid all the stupid easy ways to kill somebody, in service to building something properly dangerous. They'll raise the stakes from "accident" to "disaster." Whether or not it works, it's gonna blow people away.
C++ is dangerous like a quiet librarian who knows exactly which forbidden tomes you're looking for. He and his... associates... will gladly share all the dark magic you know how to ask about. They'll assure you, oh no no no, the power cosmic would never turn someone inside-out, without sufficient warning. They don't question why a loving god would allow the powers you crave. They will show you which runes to carve, and then, they will hand you the knife.
This is so believable. You copy a few examples out of a textbook using cout and cin and it seems reasonably inline with other languages.
Last time I did anything on the job with C++ was about 8 years ago. Here's what I learned. It may still be relevant.
- C++14 was alright, but still wasn't everything you need. The language has improved a lot since, so take this with a grain of salt. We had to use Boost to really make the most of things and avoid stupid memory management problems through use of smart (ref-counted) pointers. The overhead was worth it.
- C++ relies heavily on idioms for good code quality that can only be learned from a book and/or the community. "RAII" is a good example here. The language itself is simply too flexible and low-level to force that kind of behavior on you. To make matters worse, idiomatic practices wind up adding substantial weight to manual code review, since there's no other way to enforce them or check for their absence.
- I wound up writing a post-processor to make sense of template errors since it had a habit of completely exploding any template use to the fullest possible expression expansion; it was like typedefs didn't exist. My tool replaced common patterns with expressions that more closely resembled our sourcecode1. This helped a lot with understanding what was actually going wrong. At the same time, it was ridiculous that was even necessary.
- A team style guide is a hard must with C++. The language spec is so mindbogglingly huge that no two "C++ programmers" possess the same experience with the language. Yes, their skillsets will overlap, but the non-overlapping areas can be quite large and have profound ramifications on coding preferences. This is why my team got into serious disagreements with style and approach without one: there was no tie-breaker to end disagreement. We eventually adopted one after a lot of lost effort and hurt feelings.
- Coding C++ is less like having a conversation with the target CPU and more like a conversation with the compiler. Templates,
const,constexpr,inline,volatile, are all about steering the compiler to generate the code you want. As a consequence, you spend a lot more of your time troubleshooting code generation and compilation errors than with other languages. - At some point you will need
valgrindor at least a really good IDE that's dialed in for your process and target platform. Letting the rest of the team get away without these tools will negatively impact the team's ability to fix serious problems. - C++ assumes that CPU performance and memory management are your biggest problems. You absolutely have to be aware of stack allocation, heap allocation, copies, copy-free, references, pointers, and v-tables, which are needed to navigate the nuances of code generation and how it impacts run-time and memory.
- Multithreading in C++14 was made approachable through Boost and some primitives built on top of pthreads. Deadlocks and races were a programmer problem; the language has nothing to help you here. My recommendation: take a page from Go's book. Use a really good threadsafe mutable queue, copy (no references/pointers) everything into it, and use it for moving mutable state between threads until performance benchmarks tell you to do otherwise.
- Test-driven design and DevOps best-practice is needed to make any C++ project of scale manageable. I cannot stress this enough. Use every automated quality gate you can to catch errors before live/integration testing, as using valgrind and other in-situ tools can be painful (if not impossible).
1 - I borrowed this idea from working on J2EE apps, of all places, where stack traces get so huge/deep that there are plugins designed to filter out method calls (sometimes, entire libraries) that are just noise. The idea of post-processing errors just kind of stuck after that - it's just more data, after all.
In my country C++ is taught as a base language along with Scratch(not a language, but yk what I mean). I recently started learning Kotlin with Jetpack Compose (the only sane way to learn Kotlin) and I realized I wasted two years of my life learning C++, with 5 more to come as it is mandatory in ICT classes.... :((
I learned c from a book from the 80s and then skipped to rust.
The only time I touched c++ was modding games in the early aughts and to try it for a couple coding challenges. I've heard templates are a thing of note when it comes to complications but not sure.
As for c# ... We don't talk about that (jk. I had to do it for one or two projects and played with unity a bit ages ago)
Instructions unclear, attempted to learn JS
I actually just started learning C++ today.
If Lovecraft were alive today one of his stories would start with this line.
We used C++ based software. Who need sanity ? Clearly overrated
They are still using Reddit, so one has to wonder if they have not abandoned sanity and intellect a long time ago.
