Does anyone know a good book for object-oriented programming for C++? In terms of high level languages I come from a Java background, but currently doing dev in C/C++. Having trouble trying to draw parallels between the two, so looking for a good book to explain how C++ handles OOP.

OOP is OOP, you still deal with classes, inheritance, interfaces, etc. The concepts stay roughly the same. C++ is somewhat not the best expressive language for those concepts. A lot of those C++ OOP books don't really teach you what you need but either just an overview of language features (may not even be related to OO), or way more into OO design.

What kind of parallels are you looking for?

The Model M is not for the faint of heart. You either like them or hate them.

The biggest differences are that C++ implements multiple inheritance (which, quite frankly, tends to obfuscate code unless used sparingly), and has a lot of excess baggage that isn't object oriented since it is essentially a superset of C (and inherits all of C's low-level features like pointers, explicit memory management, etc.)

I've always kind of viewed Java as a cleaned up derivative of C++.

I guess I'm with Flying Fox on this -- I'm not sure what sort of "parallels" you mean.

The years just pass like trains. I wave, but they don't slow down.-- Steven Wilson

Well, mostly with trying to deal with class design/structure, class inheritance hierarchies, etc.. For instance, it doesn't seem like there is any existing language support for a generic interface class. How is that accomplished in CPP? Some sort of strange virtual class or something? Or not at all?

Any class that declares one or more "pure virtual" member functions is considered to be an abstract base class, and cannot be instantiated directly. The syntax for declaring a pure virtual member function is:

virtual <function prototype> = 0;

The years just pass like trains. I wave, but they don't slow down.-- Steven Wilson

CampinCarl wrote:Well, mostly with trying to deal with class design/structure, class inheritance hierarchies, etc.. For instance, it doesn't seem like there is any existing language support for a generic interface class. How is that accomplished in CPP? Some sort of strange virtual class or something? Or not at all?

That one is easy. Don't need a book. Because C++ does not really have features for a real interface, you just need a virtual destructor to make sure that this "class" gets cleaned up (you do need to declare the destructors virtual on any derived classes, especially when you have >2 levels of inheritance after the "interface").

class RealClass : public SomeOtherClass, public SomeInterface, public SomeOtherInterface{public: RealClass() : _enabled(false) {} virtual ~RealClass() {} // pretty much should declare your destructors virtual more often than not

If you want to stay pure OO, you just sort of follow the above. Now you can start "cheating" a little bit by refactoring implementations into some "intermediary" base class. Like in the above example, the "property" pretty much will be the same throughout your hierarchy, you can either use an intermediate derived class to put the implementation there, or just put into the "interface" class (the cheating part). A lot of people tend to put the prefix "I" in front of the class name to denote an interface, but the notation is somewhat religious that depends on who you talk to.

I think I start to see what you need. C++ Coding Standards is what I recommend, but it covers more than the OO side of things, but (almost) all of C++. However, for class design/structure and inheritance hierarchies you should still use regular OO principles and design patterns. These concepts should remain more or less the same across languages.

Edit: PS: Coming from Java, you will need to read up on the RAII pattern (no one link I would recommend, go read up on what you can find from your favourite search engine), but it does not really have to do with high level OO.

The Model M is not for the faint of heart. You either like them or hate them.

just brew it! wrote:The biggest differences are that C++... is essentially a superset of C (and inherits all of C's low-level features like pointers, explicit memory management, etc.)

I strongly disagree. It may have started that way, but modern C++ is a very rich language all its own, and only works best when you move away from C paradigms. Logically, I feel it's far more useful to consider C++ a deep object-oriented language with very good C compatibility.

just brew it! wrote:The biggest differences are that C++... is essentially a superset of C (and inherits all of C's low-level features like pointers, explicit memory management, etc.)

I strongly disagree. It may have started that way, but modern C++ is a very rich language all its own, and only works best when you move away from C paradigms. Logically, I feel it's far more useful to consider C++ a deep object-oriented language with very good C compatibility.

Yes, I agree that is how it is *intended* to be used. But in the real world, you see an awful lot of what I would call "hybrid code," and the language itself does nothing to prevent (or even discourage, for that matter) this.

The years just pass like trains. I wave, but they don't slow down.-- Steven Wilson

just brew it! wrote:The biggest differences are that C++... is essentially a superset of C (and inherits all of C's low-level features like pointers, explicit memory management, etc.)

I strongly disagree. It may have started that way, but modern C++ is a very rich language all its own, and only works best when you move away from C paradigms. Logically, I feel it's far more useful to consider C++ a deep object-oriented language with very good C compatibility.

Yes, I agree that is how it is *intended* to be used. But in the real world, you see an awful lot of what I would call "hybrid code," and the language itself does nothing to prevent (or even discourage, for that matter) this.

Well I agree, which is why I'm trying to do my part to discourage it here! There are numerous benefits to embracing the newer C++ styles.

As others have said, but I'll make it simpler: an Interface is just a Class, with the expectation that it only be derived and not directly used.

To formalize the prevention of use, you can do the pure virtual thing, which prevents the class from being used itself, but still allows it to be derived (this makes it abstract as well).

You can also do other tricks like making the constructor(s) protected rather than public, which means only a derived class can instantiate the base class (this makes it potentially non-abstract, as in it may be a fully functional class, but it's still derive-only because it cannot be instantiated without being derived).