Is C++ Object Oriented?

[Jonathan Shopiro]

> The phrase "object oriented" has been used to describe C++. 
> While the semantics of defining "object oriented" can get
> tricky, I wonder if this term should be used to describe C++. A
> crucial difference which I see between C++ and more unambiguously
> object oriented languages, like Objective C, Smalltalk, and
> Lisp Flavors, is that the unit of encapsulation in C++ is the
> *class* rather than the individual member of that class. 
> Member functions can access the "instance variables" (or
> private parts, as they are called in C++) of any member of
> the class. This has important implications for encapsulation
> and data security.
> 
> In general, I find this aspect of C++ places it into the category
> of "abstract type"/"module" languages, like Modula-2 and CLU
> rather than "object-oriented" languages, like Smalltalk and
> Lisp Flavors.
> 
> 		Jim Kempf		kempf at hplabs

You are right that C++ member functions can access private members of
all objects of their class, but I think it is still reasonable to call
C++ O-O, because when a member function executes, it always is as a
member of some particular object, and that object is part of the
function's environment.

For example, if 'MyType' is a class with data member 'x' and function
member 'foo' (suppose 'foo' has no arguments).

	class MyType {
		int	x;
		void	foo();
	};

Now suppose 'a' and 'b' are external or accessible static objects of
class MyType.

	MyType a, b;

In the body of 'foo' I can access the members of both 'a' and 'b' but
I have to name the object explicitly.

	void MyType::foo()
	{
		// ...
		MyType	zot;
		// ...
		a.x + b.x + zot.x
		//
	}

However this kind of code is rarely seen and I agree, more modular than
object oriented.  (Reflecting its heritage, C++ is more concerned with
allowing you to do the things you want than preventing you from doing
things you shouldn't).  The usual case is that the object is implicit
-- that is, part of the function's environment.

	void MyType::foo()
	{
		// ...
		x
		//
	}

Here 'x' refers to THE object (called 'this' in C++ or 'self' in
Smalltalk-80(TM)), so if I execute

	a.foo()

then 'x' refers to 'a.x' and similarly for 'b' or any other object of
class MyType.

My own favorite litmus test for O-O languages is that it should be
straightforward to have a bunch of different classes that each have a
member function 'foo' (different in each class), and have a
heterogeneous list that can hold a mixture of objects from any of those
classes, and pass the list to a function that can properly execute
'foo' for each element of the list.  Of course C++ passes this test.

The distinction between C++ and Smalltalk-80(TM) in this regard is
interesting -- in ST80 you can put any objects on a list, but if you
get the wrong kind of object (whose class doesn't have a 'foo') on the
list, you get a run-time error when you try to execute 'foo' for that
object.  In C++ the classes all have to be derived from a base class
that has a member function 'foo' (this doesn't seem to be too much of a
problem in practice), but the error of putting the wrong kind of object
on the list is caught at compile time.  Also the (admittedly tedious)
compilation of C++ yields much better performance at run-time.
-- 

		-- Jonathan Shopiro
		   AT&T Bell Laboratories
		   600 Mountain Avenue
		   Murray Hill, NJ 07974
		   (201) 582-4179
		   allegra!ulysses!jes