Is Cee Plus Plus Object Oriented

CeePlusPlus has long been the brunt of criticism, much of it deserved. That said, billions of lines of productive code have been written in it (and this continues to this day). This page is not intended as a general critique or defense of CeePlusPlus, but instead examines one oft-heard claim from some C++ detractors - that C++ is not object-oriented. AlanKay, the inventor of SmalltalkLanguage, is famous for saying "I invented the term ObjectOriented, and C++ isn't what I had in mind". Unfortunately, he doesn't supply us with a definition of what he does have in mind.

One common definition of OO (admittedly found in many C++ texts) is that it involves "PolymorphismEncapsulationInheritance". Two apparent flaws in that definition betray its C++ bias; "inheritance" is used when the more generic notion of subtyping will suffice; and what is meant by polymorphism is really subsumption - the ability to use a subtype in a context where a supertype is expected. There are many other types of polymorphism (see CategoryPolymorphism) which are considered outside the scope of OO (though one of them, ParametricPolymorphism, is implemented in C++ via templates).

Even with this refactoring, which gives us "subtyping, subsumption, and encapsulation" (with the remaining caveat that the first two are mostly applicable in statically-typed languages, though dynamic typing allows us to do the same stuff - and more), C++ fits all three bills.

Arguments against CeePlusPlus being OO seem to fall in the following categories:

An additional feature or capability, needed for "true" OO, is missing in C++. The most commonly mentioned such features are GarbageCollection, with introspection and DynamicTyping a bit behind. GarbageCollection, or the lack thereof, is the biggest differentiator between C++ and the other OO languages out there - and the argument goes that without automatic memory management, the higher level of abstraction afforded by OO is not possible.
To qualify as OO, a language must be pure. SmalltalkLanguage is pure OO; everything is an object. Hybrid languages like C++, with OO features and a bunch of other stuff to boot, don't qualify. (Of course, this excludes many other languages as well, such as ObjectiveCee. Even Java, which comes close, isn't pure OO).
A more specific instance of the prior argument - C++ has first-class types that aren't objects. (So does Java). To some, this excludes it from the set of OO languages.

GarbageCollection is an implementation feature, not a language feature - and regardless, it can be implemented using C++. Saying C++ needs GarbageCollection to be OO is akin to saying that C needs stdio to be procedural. Anyone arguing that a language must abstract away all low-level features to be OO is trying to push their own proprietary definition of OO and should be ignored. OO isn't about achieving maximum abstractness, it's about being a better model than procedural for all the various problem domains we encounter.

Garbage collection is, in most cases, a language feature. Smalltalk, Java, etc. implementations are required to have it; neither of those languages have any means to manually reclaim an object that is no longer used. Likewise, there are many reasons that GarbageCollection in C++ is difficult (destructor semantics, inability to tell the difference (at runtime) between a pointer and an int, etc. It's been done; but it's easy for unfriendly C++ programs, or overly-aggressive optimizing compilers, to break.

So the gist is that CeePlusPlus isn't OO because for GarbageCollection to work properly, everything must be an object? Or memory operations must be codified in such a way for GarbageCollection to work?

No; the argument is that OO programs should represent a higher level of abstraction; and manual memory management breaks that abstraction.

Good point - however most claim Java is OO, yet it's GarbageCollection breaks sometimes. Of course I prefer using a MemoryTracker? to GarbageCollection - I can code a test to see if any pointers weren't deallocated properly.

Guess what? Your MemoryTracker? most likely has a tracing GarbageCollector under the hood - but one which doesn't free the garbage it discovers; instead it reports it as a MemoryLeak. See RationalPurify for more on how this works.

Personally I think GarbageCollection is often an anti-pattern that encourages overly-loose memory practices.

GarbageCollection isn't always a panacea, and it still has performance issues for many applications. Furthermore, GarbageCollection can't collect all garbage; only those objects not reachable from the RootSet?. It is easy to write programs that will run out of memory quickly even with a garbage collector - simply leave a bunch of pointers lying around to objects you no longer intend to use.

That said, the presence of a GarbageCollector does eliminate several classes of bugs. Many types of memory leaks (including the unrecoverable kind where an object isn't freed but no references to it exist), and all of the nastier bugs associated with freeing objects twice.

I guess it's a matter of technique. My memory tracker does a few things:

Secondary memory usage tracking - the OS in many embedded systems have terrible memory usage reporting
When the application exits, it display what pointers were still unfreed(I think it's good technique to free all memory before exiting - helps track down memory leaks)
In debug mode, When deallocating a pointer, it ASSERTS that the pointer is valid - something GarbageCollection can do too.
In debug mode, The memory alloc/free records include the source file and line number, at exit all that is dumped to the IDE's format, where a double-click takes you directly there.

I think the big difference in approach is that although GarbageCollection can be used to catch memory errors, often it is often used to "forget about memory issues" - which isn't the same thing as moving to a higher abstraction level. Maybe manual memory tracking is the halfway point. Newbies need garbage collection to focus on the abstraction, later they want tight control, after understanding the rules, GarbageCollection may cut down on cruft. Maybe it's a ShuHaRi issue. People seem to have a problem with manual memory tracking because it's "too manual" - like bit-twiddling. I don't agree with that philosophy, low-level details aren't something to be ignored, just abstracted. People who prefer GarbageCollection to cut down on cruft have a much better argument.

I'm 63/64 white, and 1/64 native American (roughly) - does that mean I'm not white?

Nowadays, no. Of course, at one point in the history of the UnitedStates, having any African biological heritage made essentially made you "black", even if it the majority of your blood was of European origin. (Nowadays, this particular standard no longer applies, at least not legally).

Who claims that everything must be an object to be OO? That sounds like an arbitrary decision that wasn't based on real-world feedback. Preventing choice isn't power, it's a flaw - real power means being able to break rules when deemed necessary. I don't think OO means ObjectObsessive?.

I think the best argument that CeePlusPlus isn't object oriented is that "CeePlusPlus lets the developer choose what level of OO to use". Remember, the procedural vs. object wars are not over.

I know we're all programmers here, but some of us who share AlanKay's opinion that CeePlusPlus is not what he had in mind are talking about the overall experience, not a checklist of features and benefits. Some things - even important things - are soft rather than hard. I would be very hard pressed to describe the difference between an intimate experience dominated by lust and one dominated by love. It would be very wrong to conclude, therefore, that no such difference exists.

For me, the closest I can come to answering the question IsCeePlusPlusObjectOriented inevitably involves a comparison with the SmalltalkLanguage, because for me Smalltalk is the canonical object-oriented environment. I therefore think it might be more helpful think in terms of soft, rather than hard, aspects. I view the question as more like a comparison between CeePlusPlus and Smalltalk along dimensions like:

How do I define a new class? Type it in in both languages
How do I specialize an existing class? Inheritance
How do I change fundamental behavior of the environment? Much easier to do in Smalltalk than C++; C++ isn't designed to be mutable in this fashion. Of course, a good question is "should you"? C++ allows you to do wonderful (or horrible) things with pointers, after all; but must Smalltalker's don't consider the lack of PointerArithmetic and such in Smalltalk to be a deficiency.
How do I address functional requirements unknown when the language was created? Use - or create - a different language. Smalltalk allows you to extend it easily to meet new requirements, thus specializing the language, far easier than creating a whole new one.
How do I discover what my code is doing? Do you mean you as the programmer, or you as the program performing introspection?
How do I discover what somebody else's code is doing? See previous answer
How do I discover what I want my code to do? Ask yourself. Certainly from examining the code, you can only discover what it actually does, not what the programmer intends. DoWhatImeanAndNotWhatIsay?, etc.
How do I discover what I want somebody else's code to do? Ask him. Read his documentation. Read his comments. See above

I started doing object oriented code twenty years ago, because Smalltalk-80 was compellingly better at answering these sorts of questions than any of the procedural alternatives. CeePlusPlus has always been, at best, an effort to stretch the CeeLanguage into a Smalltalk-like shape. I agree with AlanKay that the exercise failed. Whatever CeePlusPlus is, it is not what AlanKay had in mind when he coined the term "object oriented".

Well, AlanKay might have invented the term, but the paradigm was invented by Nygaard and Dahl. Now if we look for ObjectOrientedProgramming as defined by Nygaard in his seminal "Beta book", there's nothing like the laundry list above.

So let's rephrase things a bit:

Is C++ Object Oriented ? Well, it supports Object Oriented Programming as per NygaardClassification, so I'm afraid we have to say that it is...or say that it can be.
Is C++ what AlanKay had in mind ? It isn't, because it's not Smalltalk.

[An interesting question. Outside of Smalltalk, what OO languages does AlanKay like? (Lisp) We know he dislikes C++ and Java both... has he weighed in on Eiffel, for example? Getting him and BertrandMeyer (who has some rather unpleasant things to say about Smalltalk, as well as C++ and Java) to go twelve three-minute rounds on what constitutes a proper OO language...well, I'd buy a ticket to see that.]

Everybody should be happy now.

I'm happy because I just realized a lot of people "own" the definition of OOP, so disagreement over "proper OO" is inevitable. It doesn't matter who drew it up, named it, implemented it best, adapted it best, or discovered the most advanced patterns.

Nobody owns the definition. Since KristenNygaard and OleJohanDahl are widely recognized as the inventors, most people would recognize NygaardClassification as authoritative.

If somebody else comes with an obviously different definition one the following cases may apply:

it is a specialization (refinement) of the original.
the author is an ignoramus.
it is a valid idea but should have a different name.

If both C++ and Smalltalk are ObjectOriented, then Smalltalk needs a new classification:

Smalltalk has SingleRootedHierarchy?.
Smalltalk has SingleInheritance. This ia a GoodThing, at least when compared with C++ MultipleInheritance.
Smalltalk has GarbageCollection.
Smalltalk blocks are objects, while in C++ blocks are built-in gibberish: It is not expressed as something else in the language.
- Other than the LexicalScoping aspects of Smalltalk blocks (and the fact that ^whatever exits the enclosing method, not just the block), one can do block-like things well enough in CeePlusPlus with FunctorObjects. Of course, it's LexicalScoping that is the most powerful feature, so C++ can not do most block like things.
Having the language to express the language in itself allows for redefinition, in runtime. This is important. You can create new control structures in Smalltalk while you can't in C++.
- In my experience, this is more an issue of syntactic sugar than anything else. Can't create "control structures"? Well, you can't create something in C++ that has curly-brace syntax, that not being overloadable... but you can create things, either with templates, macros, or ordinary functions, that act like control structures in most other respects. As a experienced C++ programmer, there are lots of things about the language that annoy me; this is seldom one of them. It's far more than syntactic sugar, it's a different way of programming, specializing the language to allow the program to be expressed more clearly in less code, this only works if you can extend the language cleanly.

(And it has utterly no bearing whatsoever on whether or not C++ is ObjectOriented).

That's what a C++ programmer would say, because his idea of ObjectOriented is different than a Smalltalkers.

If ObjectOriented is to have any useful meaning, it should be a consistent one.

In C++ you create a class with a file containing strings in a special format, in Smalltalk you send a message to the Class object to create a new class. Smalltalk is a live system of objects, C++ is a bunch of strings until compiled and executed, it's not a runtime system.

Something which is simultaneously a strength and a weakness - for both languages

If anyone could ever agree on a single definition of ObjectOriented there wouldn't be so much disagreement, but I imagine when a Smalltalker see's a C++ environment, he feels like it's missing too many things Smalltalk has, to be considered fully OO. Whether correct or not, it's certainly an understandable position.

But that's the problem. None of the definitions of OO, even that promulgated by AlanKay himself, says anything about what you are discussing. None of the DefinitionsForOo I've read (at least those worthy of being taken seriously) claim anywhere that an integrated environment, an ImageBasedLanguage, or the ability to tweak the runtime system, etc., are requirements for OO-ness). I'll agree that Smalltalk has lots of things C++ lacks, the latter being a highly static language with runtime intentionally decoupled from development environment. No argument there. But what does that have to do with OO? Not a lot. The fundamental properties of OO, C++ has. Now a case can be made that C++ is a bad OO language, at least for certain programming tasks. C++ has many disadvantages; it requires a large AmountOfTyping? to get anything done. And the low-level programming model makes it easy to shoot yourself in the foot. There are many things that I would much rather use Smalltalk, Java, Python, or something DotNet for. There are other programming tasks that C++ excels at that I wouldn't let any of the other languages anywhere near. But this has little if anything to do with OO.

I don't disagree with any of that, I believe in NygaardClassification, but my point was there is no one single definition that everyone accepts, so many form their own opinions about what constitutes OO. A Smalltalker is likely to have a vastly different opinion than a C++ programmer because of that environment. I'm not claiming they're right or wrong, just that it is quite understandable that they have different idea's of OOness. Smalltalk is pervasive with objects, far more so that C++, so regardless of the true definition of OO... Smalltalk is far more "something" than C++, most want to call that something OO.

A few people in the Smalltalk community seem to equate ObjectOriented with SmalltalkLanguage - and Smalltalk is one of the purest OO languages out there, so at first blush this is reasonable. But the error is the insistence that deviation from Smalltalk (or the Smalltalk way of doing things) implies deviation from OO. C++ deviates a hell of a lot from Smalltalk; BjarneStroustrup designed it that way. (Not that he thought Smalltalk was bad; however he was addressing a different problem-set). "If you want Smalltalk, use Smalltalk" is a common Stroustrup quote. But C++ is certainly capable of doing reasonable OO programming.

Many people making these arguments confuse SmalltalkLanguage with the combined language, IDE and application framework.

I've used a lot of different programming tools since starting OO development about 12 years ago. One of the best browsing and editing environments (ACI's Object Master) for C++ is no longer available - it used a Smalltalk-style 3 pane browser.

Currently I'm doing a lot of work in RealBasic which bundles an OO language with a clean cross-platform application framework (class Mac, OS/X, Windows and Linux) including graphics and sound. It reinforces for me the huge difference the application framework alone makes and how much value there is when the IDE knows the framework, not just the language. -- AndyDent

CategoryCpp