Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site alice.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!alice!bs
From: bs@alice.UucP (Bjarne Stroustrup)
Newsgroups: net.lang,net.lang.c
Subject: Is C++ Object Oriented?
Message-ID: <4801@alice.UUCP>
Date: Sun, 12-Jan-86 22:32:39 EST
Article-I.D.: alice.4801
Posted: Sun Jan 12 22:32:39 1986
Date-Received: Tue, 14-Jan-86 04:00:30 EST
Organization: Bell Labs, Murray Hill
Lines: 55
Xref: watmath net.lang:2035 net.lang.c:7572

> 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''.