Xref: utzoo comp.lang.eiffel:285 comp.lang.c++:3725
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!mcvax!ukc!etive!aiai!jeff
From: jeff@aiai.uucp (Jeff Dalton)
Newsgroups: comp.lang.eiffel,comp.lang.c++
Subject: Re: Eiffel vs. C++
Message-ID: <543@skye.ed.ac.uk>
Date: 19 Jun 89 14:55:00 GMT
References: <2689@ssc-vax.UUCP> <150@eiffel.UUCP>
Sender: news@aiai.ed.ac.uk
Reply-To: jeff@aiai.uucp (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 56

In article <150@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes:
>From article <2689@ssc-vax.UUCP> by dmg@ssc-vax.UUCP (David Geary):

>Eiffel software is organized in autonomous software units (classes),
>meant to be compiled separately. There is no main program.  [...]  In
>contrast, I understand that C++ still follows the traditional C model.
>[...]  ``A C++ program typically consists of many source files, each
>containing a sequence of declarations of types, functions, variables,
>and constants''. This is very far from the object-oriented model of
>software decomposition.

It is true that C++ does not enforce object-oriented decomposition
or provide explicit support for it.  Nonetheless, a C++ programming
environment could provide such support.  And it is possible to make
reasonable decompositions in C and C++, even though the compilation
units are files, and even without any special environmental support
that "hides the files".

So I don't think C++ prevents the programmer from doing objet-oriented
decomposition, but I'll have to leave the details to those who know
more about C++ than I do.

>Multiple inheritance
>
>    Multiple inheritance is fundamental in the Eiffel approach. We made
>every effort to handle it in a very clean way; name clashes, in particular,
>are treated in what I believe is the right way. (More precisely, I do not
>know of any satisfactory solution in any other language. This is a strong
>statement, and proponents of other languages are welcome to respond to the
>challenge.)

I think the statement is too strong as it stands, because "satisfactory"
isn't defined.  It also makes it difficult for other languages to
respond to the challenge.

But I'm not sure it's possible to make strong conclusions in any case.
Suppose someone said the Eiffel solution was unsatisfactory.  How could
this be resolved?  IN the end you may just have different goals.

>Garbage collection

>As far as I know, C++ systems do not support garbage collection,
>which would be extremely difficult if not impossible to implement
>because of the presence of C types and mechanisms.

As far as I know, it is possible to provide garbage collection for C,
and some systems have actually done so.  The GC has to be "conservative"
in that it must regard anything that might be a pointer as a pointer.
So there might be some garbage it can't collect, but it will never
collect non-garbage.

It is possible to write some things in C that will cause such systems
to go wrong, but (again, as far as I know), all such things are regarded
as nonportable.  So conforming programs can't do them.

-- Jeff