I feel like I’ve done enough with C, and now I want to start learning C++ as the next step in my journey.

At the moment, I’m following the usual approach reading books, watching videos, and writing code but I’d like to know if there’s a more effective way to learn C++.

I want to ask how you approached learning C++. Did you follow any specific strategy or roadmap that helped you understand it better?

 

One uses C++ instead of C when C++ has features that are not already implemented in C.

If you cannot find a reason to migrate to C++, then stay with C.

 

I feel like I’ve done enough with C, and now I want to start learning C++ as the next step in my journey.

At the moment, I’m following the usual approach reading books, watching videos, and writing code but I’d like to know if there’s a more effective way to learn C++.

I want to ask how you approached learning C++. Did you follow any specific strategy or roadmap that helped you understand it better?

C++ is a minefield, filled with weird syntax, foot guns and all sorts. I've not used C++ very much at all (for those reasons) but have designed languages and compilers for languages. My advice would be to use C++ in a very disciplined way, it can lead to messy code more so than C and for someone learning its likely easy to develop bad habits.

So I'd suggest looking at some existing standard ways of using it, perhaps use some vendors own coding standards for example, at least that way you'll have some safety rails as you learn it.

As for learning itself I'd probably start by writing small examples and experimental code on a PC, just work in Visual Studio (Community Edition is free) without any concern for microcontrollers initially.

Also use AI like Copilot or something to ask questions, a well stated question on programming language use is one of the most useful things AI can do for you.

 

If you are using C++, it should be because you want to develop a program in an object-oriented way. So the focus should be on understanding object-oriented programming and how to do that using C++.

Unfortunately, C++ was written as a superset of C, meaning that you can write non-object-oriented code in C++, which tends to lead to an ungainly mish-mash of the two in the same program. You might consider first learning something like Java so that you can learn how to write programs from an object-oriented perspective. It is a very different mindset, with its advantages and disadvantages.

I've done very little with C++, because I think that other languages do OOP (Object-Oriented Programming) much better. I've had very limited exposure to C#, but I really liked it. I just didn't want to be tied to the .NET framework. My current go-to language is Python, but like C++ you can mix and match OOP and non-OOP and so it requires discipline on the part of the developer.

One problem that I had in trying to learn OOP using C++ was the expectation that, since it was a superset of C, that my understanding of the internals of how C worked would translate across and it doesn't, at least not until you understand some of the hidden things that the compiler does behind the scenes. By starting with Java or something like that, you are in a better position to accept OOP concepts on their own terms instead of bringing preconceptions with you.

 

C++ ... can lead to messy code.

Then you're doing it wrong.

Done properly, I find C++ cleaner than C, and easier to follow.

I've always loved OOP, I just never get the opportunity to write it anymore.

 

If you cannot find a reason to migrate to C++, then stay with C.

My main reason for learning C++ is not necessarily to replace C, but to understand object-oriented programming concepts

 

My main reason for learning C++ is not necessarily to replace C, but to understand object-oriented programming concepts

Just be sure that you focus on writing programs using objected-oriented programming concepts. C++ makes it too easy to avoid them and the temptation to do so can be very high because you already know how you would do X, Y, and Z in C, so you don't see why you should "waste the time" figuring out how to do it properly in an object-oriented way. That's where the mish-mash mess comes from.

 

Then you're doing it wrong.

Done properly, I find C++ cleaner than C, and easier to follow.

I've always loved OOP, I just never get the opportunity to write it anymore.

Well I don't use C++, if I did I'd do it with a disciplined approach as I said; managing object lifetimes, ownership and cleanup must be done robustly.

I've looked at C++ several times but formed the view that learning it would be more cost than benefit really, I already use C# for most of my (non MCU) work and that's a slicker OO experience, C++ is too dated to appeal to me as a language.

As for OOP be careful, the term doesn't have a universal definition, it's a mix of ideas and different OO languages implement different ideas. For example inheritance once the key idea that people were exposed to when all the OO hype came out, is now seen as only having a very narrow application, interfaces are no emphasized much more.

 

My main reason for learning C++ is not necessarily to replace C, but to understand object-oriented programming concepts

Don't use C++ then, Java is a much better learning language because it mainly forces textbook object-oriented programming concepts.
https://rbberger.github.io/assets/files/smr2574/OOPConcepts.pdf
https://medium.com/quick-recap-of-e...oriented-programming-oop-in-java-ae2ff8e07c36


https://alex-ber.medium.com/richard-feldman-the-return-of-procedural-programming-0eeb2fba3840
The trend in programming styles is shifting away from object-oriented paradigms toward functional and procedural approaches. Languages like Go and Rust have omitted traditional object-oriented features such as classes and inheritance, while Swift encourages the use of plain structures over classes.

 

Well I don't use C++, if I did I'd do it with a disciplined approach as I said; managing object lifetimes, ownership and cleanup must be done robustly.

I've looked at C++ several times but formed the view that learning it would be more cost than benefit really, I already use C# for most of my (non MCU) work and that's a slicker OO experience, C++ is too dated to appeal to me as a language.

As for OOP be careful, the term doesn't have a universal definition, it's a mix of ideas and different OO languages implement different ideas. For example inheritance once the key idea that people were exposed to when all the OO hype came out, is now seen as only having a very narrow application, interfaces are no emphasized much more.

The shift of focus to interfaces is a pretty natural evolution. Why were "objects" emphasized originally? It was the notion that the user interacted with an object at a level of abstraction consistent with that notion and the implementation details were hidden away. It didn't matter how a report printed itself, just that it did. Interfaces merely expand that concept. Instead of having a linked list that has methods at the top-level interaction of a linked list, you have an interface for a higher-level of abstraction for a Queue and it doesn't matter (functionally) whether you choose to instantiate that Queue as a linked list or some other object that implements the Queue interface. It is merely further divorcing the functional behavior from the underlying implementation.

 

You might consider first learning something like Java so that you can learn how to write programs from an object-oriented perspective.

I was going to say the same thing. Java is a much cleaner and more natural implementation of object oriented programming. And the basic syntax is still based on C.

 

The shift of focus to interfaces is a pretty natural evolution. Why were "objects" emphasized originally? It was the notion that the user interacted with an object at a level of abstraction consistent with that notion and the implementation details were hidden away. It didn't matter how a report printed itself, just that it did. Interfaces merely expand that concept. Instead of having a linked list that has methods at the top-level interaction of a linked list, you have an interface for a higher-level of abstraction for a Queue and it doesn't matter (functionally) whether you choose to instantiate that Queue as a linked list or some other object that implements the Queue interface. It is merely further divorcing the functional behavior from the underlying implementation.

Well, having a class hierarchy introduces dependencies in such a way that changing the base class can lead to undesired changes in derived classes that is to say contracts can break.

Modern design strategies use interfaces to support (lofty sounding) "dependency injection". Constructors that accept args that are interfaces rather than concrete (base) classes, can never break in the same way because there is no base class anymore.

This is used as a bedrock strategy for example in modern ASP.NET web app design and web service design, web service API logic is decoupled from actual implementations of databases, external APIs, logging etc. That lets us run lots of unit tests against a web API without needing a web server or anything.

Once one has adopted these ideas the benefits are big and make a lot of difference to code robustness, testing scope etc.

I use C# which looks like Java to an extent but has numerous strengths and additional capabilities.

 

I use C# which looks like Java to an extent but has numerous strengths and additional capabilities.

At one level, and from a highly simplified perspective, C++ was the first widely adopted OOP language largely because they made it a superset of C in order to make it more palatable to the large population of C developers. But what many people forget is that C++ was not just an object-oriented language, but was intended to be a multi-paradigm language that allowed developers to integrate pieces of code that, individually, lent themselves to one of several programming approaches. Unfortunately, because the language intentionally did not enforce strict adherence to OOP principles, developers trying to write OOP programs could easily drift away from those principles without realizing it, which could lead some to believe that they were writing OOP programs when they really weren't. C++ requires developers to exercise self-discipline to develop programs that tightly toe the OOP line. Not surprisingly, other weaknesses were discovered as people trying to write good OOP code gained experience with the language. So future versions of the language incorporated fixes and new features, but were constrained by having to live with the existing syntax structure. Java came along, in significant part, to "fix" some of these deficiencies and add capabilities whose value was becoming more apparent and it succeeded to a large extent, but made its own missteps and oversights, plus experience with a language that strongly enforces the OOP paradigm revealed further weaknesses in the conceptual framework and opportunities for cleaner constructs and features, that resulted in some kludgy add-ons in later versions. C# is, in some respects, a next step in the process and it made significant improvements in the cleanliness in which it incorporated the later features in a coherent manner. But it will inevitably end up having it's own kludgy enhancements over time which will very possibly result in yet some new language in the OOP lineage that pushes further while cleaning up the past.

 

At one level, and from a highly simplified perspective, C++ was the first widely adopted OOP language largely because they made it a superset of C in order to make it more palatable to the large population of C developers. But what many people forget is that C++ was not just an object-oriented language, but was intended to be a multi-paradigm language that allowed developers to integrate pieces of code that, individually, lent themselves to one of several programming approaches. Unfortunately, because the language intentionally did not enforce strict adherence to OOP principles, developers trying to write OOP programs could easily drift away from those principles without realizing it, which could lead some to believe that they were writing OOP programs when they really weren't. C++ requires developers to exercise self-discipline to develop programs that tightly toe the OOP line. Not surprisingly, other weaknesses were discovered as people trying to write good OOP code gained experience with the language. So future versions of the language incorporated fixes and new features, but were constrained by having to live with the existing syntax structure. Java came along, in significant part, to "fix" some of these deficiencies and add capabilities whose value was becoming more apparent and it succeeded to a large extent, but made its own missteps and oversights, plus experience with a language that strongly enforces the OOP paradigm revealed further weaknesses in the conceptual framework and opportunities for cleaner constructs and features, that resulted in some kludgy add-ons in later versions. C# is, in some respects, a next step in the process and it made significant improvements in the cleanliness in which it incorporated the later features in a coherent manner. But it will inevitably end up having it's own kludgy enhancements over time which will very possibly result in yet some new language in the OOP lineage that pushes further while cleaning up the past.

I've toyed with learning C++ for some years, but I'm experienced enough to know it will demand a considerable investment in my time and I have no professional motive for the language either.

I dabble in STM32 boards from time to time and find C (which I used professionally for years on minicomputers) adequate for anything I'm likely to attempt to write for such boards.

So if I was going to learn and work with a new language for some kind of personal interest it would be something like Haskell or Scheme I think, where the entire paradigm is fundamentally different and reminiscent of mathematics with no side effects, no variables, no loops and so on, that's a very refreshing experience.

Functional languages compel one to think about algorithms that manipulate data, in new and fascinating ways.