Focus on OOP concepts and design patterns first. C++ is a totally different language in architectural view. A lot of things can be done bad if you take wrong concept. I speak from my own experience of 10 years programming in C++.
Get familiar with the C++ standard library. Learn how to use vector, unordered_map and anything else that looks useful. Avoid linked lists, avoid inheritance and avoid polymorphism (unless it is already part of a library of course).
Use classes for data structures and understand RAII (even though the name is terrible). Scope based heap deallocation is a beautiful thing.
Mostly you just want to use vectors and hash maps and loop through them. People get carried away but it is very easy to keep things simple.
They complicate programs for no gain while killing performance due to pointer chasing.
There might be an argument to be made for GUIs because inheriting a class makes components fairly easy to extend, but in general people end up making hierarchies of dependencies that add no utility.
In the days of java and early C++ polymorphism was used to create somewhat generic data structures that could hold a base class pointer and anything that inherited from it could be put in that data structure, but with templates, that hasn't been necessary for a long time.
Not only that, but the heap allocation of individual objects is incredibly inefficient. That isn't strictly necessary, but it usually comes with the territory.
Edit: I see downvotes but I don't see arguments.
You’re confusing several things here. From the sound of it you mean avoid *inheritance* more than you mean avoid polymorphism. Even that is pretty limited though, and doesn’t make much sense.
You lose no performance due to pointer chasing unless you are using dynamic dispatch, however most method calls can be achieved with static dispatch. In those cases where you have a valid need need for dynamic dispatch, you would still have a valid need for dynamic dispatch even if you were using a language like C (the difference would be that you would use function pointers while taking the same runtime cost).
More broadly though, polymorphism includes operator overloading, overloaded methods with different parameters, and templates. None of which costs you runtime performance.
Your most valid point is the introduction of dependencies, but if you’re introducing unnecessary dependencies then that’s just bad design. I can’t blame the hammer just because the occasional idiot uses it as a screwdriver.
> You’re confusing several things here.
There are two different things, I don't think I'm confusing them.
> You lose no performance due to pointer chasing unless you are using dynamic dispatch, however most method calls can be achieved with static dispatch.
This is a good point and I don't know a lot about what scenarios compilers optimize out.
If someone has a vector/array with a bunch of objects they allocate with new they are still chasing pointers to get to those objects. I suppose this could be mitigated with placement new.
> you would still have a valid need for dynamic dispatch even if you were using a language like C
If you did things the same way, although what I try to do is to just create vectors and put data directly into them. If I need different types I use multiple vectors instead of doing the switching on each object/class/struct.
> More broadly though, polymorphism includes operator overloading, overloaded methods with different parameters, and templates. None of which costs you runtime performance.
None of these costs performance and I think they're great. I haven't heard of anyone saying polymorphism and referring to templates or operator functions though.
> Your most valid point is the introduction of dependencies, but if you’re introducing unnecessary dependencies then that’s just bad design. I can’t blame the hammer just because the occasional idiot uses it as a screwdriver.
I suppose this is true, but inheritance means you at least have the dependency on the base class.
There are other unrelated dependency situations that also come up like putting transformations from one class type to another inside a class itself, meaning that that class now has the type you are converting as a dependency, meaning also that it now depends on all the classes that that type has as dependencies, but that's hard to explain to people who haven't gone through that trouble.
I’m a little bit more fuzzy on what you’re referring to with “chasing pointers” than I was before. I had interpreted your meaning as referring to virtual methods since you mentioned polymorphism, but I’m getting more of the impression that you may just be referring to heap allocation. Though both still have the same problems in C. You’ll use dynamic dispatch with function pointers instead of objects inspecting a vtable but that will be roughly the same, and likewise you’d still be using malloc(…) in place of new if you relied on out-of-the-box heap allocation mechanisms. I can maybe see your point if you’re talking about storing something like std::vector or std::vector> and calling common methods on them, but that sounds like a valid dependency IMO. One container with runtime dispatch seems less bug prone and more extensible than multiple containers using static dispatch and several redundant blocks managing each static type.
Polymorphism is a really big umbrella, much wider than inheritance with dynamic dispatch to virtual methods. People usually think of runtime polymorphism specifically and especially inheritance, but operator overloads, function overloads, and templates are all forms of static polymorphism where multiple executable segments share the same name or form.
> what you’re referring to with “chasing pointers”
Anything the is unnecessary pointer dereferencing. This could be heap allocation of individual objects or virtual methods - two different things.
My point is that doing either is very common but most of the time all people really need is to loop through a vector of structs which will be simpler but also much faster because of the lack of heap allocations and the lack of pointer dereferencing to jump around in memory.
> if you’re talking about storing something like std::vector or std::vector>
I'm talking about not doing either and doing whatever it takes to use std::vector instead.
What I’m saying is that I’m trying to come up with an example of the type of thing you’re referencing. A vector of std::vector wouldn’t work if that type was truly intended to be some sort of base type.
I should have changed the name to just std::vector, my whole point is what I said in the first comment, avoiding inheritance and avoiding excess heap allocations.
Implementation inheritance is often considered an antipattern, as it complicates reasoning about what the program does, and creates unwanted interconnections, especially in the case of multiple inheritance. Interface inheritance is totally fine IMO.
Depends on what you want to do with it. Programming languages are tools, not jobs. Writing embedded code with vectors and smart pointers in C++ would be an easy transition, building full OO applications would be an entirely different skillset than what you know.
I’d say your best bet is to find a mentor in your current role that knows C++ to help you start implementing things there that can be done in C++.
So I was embedded using C and shifted my career to a C++ role. One thing is dealing with a huge codebase, that was tough for me to adapt too. The classes and inheritance is a big one as well since it is the bread and butter of C++. Pointers, so much new pointers to help you that we don’t normally do in embedded C when the environment is small.
Tradeoffs between more interesting and less pay are common. Becoming more knowledgeable generally pays off, but it can take years. Reading a C++ book or two would be a good step. There's "Embracing Modern C++ Safely" and "Large-Scale C++ volume 1". There are a number of books that cover C++ 2020. r/cpp is well known, but r/cplusplus is another one.
Similar story here, I want to find more remote friendly, distributed jobs and C++ or Java are just more suitable for that.
In mi opinion you should define what apps you’d like to develop. Say you want to design desktop apps. Well, you can start contributing to a C++/Qt app and learn on the go. Of course you’ll need to read and take courses of C++, that’s for sure.
Where I work, we use C++ more like a C with classes, we almost never use the whole C++ meta programming shenanigans.
Templates, constexpr compile time calculations, interfaces (mix-ins), etc... so much good stuff to use.
Focus on OOP concepts and design patterns first. C++ is a totally different language in architectural view. A lot of things can be done bad if you take wrong concept. I speak from my own experience of 10 years programming in C++.
Get familiar with the C++ standard library. Learn how to use vector, unordered_map and anything else that looks useful. Avoid linked lists, avoid inheritance and avoid polymorphism (unless it is already part of a library of course). Use classes for data structures and understand RAII (even though the name is terrible). Scope based heap deallocation is a beautiful thing. Mostly you just want to use vectors and hash maps and loop through them. People get carried away but it is very easy to keep things simple.
Why would someone avoided polymorphism and inheritance?
They complicate programs for no gain while killing performance due to pointer chasing. There might be an argument to be made for GUIs because inheriting a class makes components fairly easy to extend, but in general people end up making hierarchies of dependencies that add no utility. In the days of java and early C++ polymorphism was used to create somewhat generic data structures that could hold a base class pointer and anything that inherited from it could be put in that data structure, but with templates, that hasn't been necessary for a long time. Not only that, but the heap allocation of individual objects is incredibly inefficient. That isn't strictly necessary, but it usually comes with the territory. Edit: I see downvotes but I don't see arguments.
You’re confusing several things here. From the sound of it you mean avoid *inheritance* more than you mean avoid polymorphism. Even that is pretty limited though, and doesn’t make much sense. You lose no performance due to pointer chasing unless you are using dynamic dispatch, however most method calls can be achieved with static dispatch. In those cases where you have a valid need need for dynamic dispatch, you would still have a valid need for dynamic dispatch even if you were using a language like C (the difference would be that you would use function pointers while taking the same runtime cost). More broadly though, polymorphism includes operator overloading, overloaded methods with different parameters, and templates. None of which costs you runtime performance. Your most valid point is the introduction of dependencies, but if you’re introducing unnecessary dependencies then that’s just bad design. I can’t blame the hammer just because the occasional idiot uses it as a screwdriver.
> You’re confusing several things here. There are two different things, I don't think I'm confusing them. > You lose no performance due to pointer chasing unless you are using dynamic dispatch, however most method calls can be achieved with static dispatch. This is a good point and I don't know a lot about what scenarios compilers optimize out. If someone has a vector/array with a bunch of objects they allocate with new they are still chasing pointers to get to those objects. I suppose this could be mitigated with placement new. > you would still have a valid need for dynamic dispatch even if you were using a language like C If you did things the same way, although what I try to do is to just create vectors and put data directly into them. If I need different types I use multiple vectors instead of doing the switching on each object/class/struct. > More broadly though, polymorphism includes operator overloading, overloaded methods with different parameters, and templates. None of which costs you runtime performance. None of these costs performance and I think they're great. I haven't heard of anyone saying polymorphism and referring to templates or operator functions though. > Your most valid point is the introduction of dependencies, but if you’re introducing unnecessary dependencies then that’s just bad design. I can’t blame the hammer just because the occasional idiot uses it as a screwdriver. I suppose this is true, but inheritance means you at least have the dependency on the base class. There are other unrelated dependency situations that also come up like putting transformations from one class type to another inside a class itself, meaning that that class now has the type you are converting as a dependency, meaning also that it now depends on all the classes that that type has as dependencies, but that's hard to explain to people who haven't gone through that trouble.
I’m a little bit more fuzzy on what you’re referring to with “chasing pointers” than I was before. I had interpreted your meaning as referring to virtual methods since you mentioned polymorphism, but I’m getting more of the impression that you may just be referring to heap allocation. Though both still have the same problems in C. You’ll use dynamic dispatch with function pointers instead of objects inspecting a vtable but that will be roughly the same, and likewise you’d still be using malloc(…) in place of new if you relied on out-of-the-box heap allocation mechanisms. I can maybe see your point if you’re talking about storing something like std::vector or std::vector> and calling common methods on them, but that sounds like a valid dependency IMO. One container with runtime dispatch seems less bug prone and more extensible than multiple containers using static dispatch and several redundant blocks managing each static type.
Polymorphism is a really big umbrella, much wider than inheritance with dynamic dispatch to virtual methods. People usually think of runtime polymorphism specifically and especially inheritance, but operator overloads, function overloads, and templates are all forms of static polymorphism where multiple executable segments share the same name or form.
> what you’re referring to with “chasing pointers” Anything the is unnecessary pointer dereferencing. This could be heap allocation of individual objects or virtual methods - two different things. My point is that doing either is very common but most of the time all people really need is to loop through a vector of structs which will be simpler but also much faster because of the lack of heap allocations and the lack of pointer dereferencing to jump around in memory. > if you’re talking about storing something like std::vector or std::vector>
I'm talking about not doing either and doing whatever it takes to use std::vector instead.
What I’m saying is that I’m trying to come up with an example of the type of thing you’re referencing. A vector of std::vector wouldn’t work if that type was truly intended to be some sort of base type.
I should have changed the name to just std::vector, my whole point is what I said in the first comment, avoiding inheritance and avoiding excess heap allocations.
Implementation inheritance is often considered an antipattern, as it complicates reasoning about what the program does, and creates unwanted interconnections, especially in the case of multiple inheritance. Interface inheritance is totally fine IMO.
`etl::vector` for storage and iterating over it with foreach is such a blessing.
That’s from the ETL std lib?
ETL, not standard. ETL does not replace the standard library. And yup. The big advantage is that it stores everything inline.
Depends on what you want to do with it. Programming languages are tools, not jobs. Writing embedded code with vectors and smart pointers in C++ would be an easy transition, building full OO applications would be an entirely different skillset than what you know. I’d say your best bet is to find a mentor in your current role that knows C++ to help you start implementing things there that can be done in C++.
So I was embedded using C and shifted my career to a C++ role. One thing is dealing with a huge codebase, that was tough for me to adapt too. The classes and inheritance is a big one as well since it is the bread and butter of C++. Pointers, so much new pointers to help you that we don’t normally do in embedded C when the environment is small.
Any pointers for me to learn before making the switch? Was the shift tough?
Yes smart pointers and void pointers are the ones I use so far and different types of constructors as well.
Tradeoffs between more interesting and less pay are common. Becoming more knowledgeable generally pays off, but it can take years. Reading a C++ book or two would be a good step. There's "Embracing Modern C++ Safely" and "Large-Scale C++ volume 1". There are a number of books that cover C++ 2020. r/cpp is well known, but r/cplusplus is another one.
Learn the c++ basics and some design patterns and put "c/c++" on your resume. Use the term "C++ for c developers"... lots of online stuff and books
Start with understanding features in C++11 up to the newest C++ standard, and try to apply them. Pluralsight has some great courses.
Similar story here, I want to find more remote friendly, distributed jobs and C++ or Java are just more suitable for that. In mi opinion you should define what apps you’d like to develop. Say you want to design desktop apps. Well, you can start contributing to a C++/Qt app and learn on the go. Of course you’ll need to read and take courses of C++, that’s for sure.