[net.lang] Is C++ Object Oriented?

kempf@hplabsc.UUCP (Jim Kempf) (01/07/86)

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. While there are pros and cons to both approaches,
there is probably something to be said for making the distinction
clear. For example, no one would call Lisp an "Algol-like" language,
nor C a "symbolic processing language", even though it's possible to
do Algol-like things in Lisp (Common Lisp even has a notion of
block structuring) and symbolic processing in C.

		Jim Kempf		kempf@hplabs

jes@ulysses.UUCP (Jonathan Shopiro) (01/11/86)

> 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@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

bs@alice.UucP (Bjarne Stroustrup) (01/13/86)

> From allegra!ulysses!mhuxr!mhuxt!houxm!ihnp4!pesnta!hplabsc!kempf 
> From: kempf@hplabsc.UUCP (Jim Kempf)
> Subject: Is C++ Object Oriented?
> Organization: Hewlett Packard Labs, Palo Alto CA
> 
> 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. While there are pros and cons to both approaches,
> there is probably something to be said for making the distinction
> clear.

The distinction was made clear in ``Data Abstraction in C'' BLTJ Oct. 1984
and is implied in the ``Rules of Tumb'' in the C++ book, but I don't believe
it is of first order importance.

C++ supports object oriented programming because it has an inheritance
mechanism. This, I believe, is the crucial tests, not the issue of the
unit of protection. Furthermore, if you consider it important to ensure that
interaction between objects of a C++ class is restricted to calls of member
functions, then that is trivially done (by human or machine). This implies
that any tricks a compiler/interpreter can do by taking advantage of
object-encapsulation can be done in in a language with class-encapsulation
for the cases where the strict object-encapsulation is desired/specified.

C++'s inheritance mechanism is very similar to Simula67's so C++ is in good
company. 

I usually say that ``C++ supports object oriented programming'' or ``C++
provides facilities for object oriented programming'', not ``C++ is an
object oriented language''. In other words, ``object oriented'' is a style
of programming, not a langauge feature. Not every application is best
handled using an object oriented style, so C++ also supports other styles.
For example, many arithmetic types are best handled using the data abstraction
paradigm. C++ is probably best understood as a ``Multi-paradigm language''
in the tradition of C where the emphasis is on facilities of doing (presumably
interesting) things rather than on facilities on preventing you from doing
(presumably bad) things.

	- Bjarne Stroustrup (AT&T Bell Labs, Murray Hill, NJ)

PS ``private parts'' is not the C++ term for an instance variable,
   the term is ``object''.