Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!csd4.milw.wisc.edu!uxc!uxc.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson
From: johnson@p.cs.uiuc.edu
Newsgroups: comp.lang.c++
Subject: Re: Eiffel vs. C++
Message-ID: <77300029@p.cs.uiuc.edu>
Date: 6 Jun 89 16:22:00 GMT
References: <2689@ssc-vax.UUCP>
Lines: 154
Nf-ID: #R:ssc-vax.UUCP:2689:p.cs.uiuc.edu:77300029:000:7246
Nf-From: p.cs.uiuc.edu!johnson    Jun  6 11:22:00 1989


> Written  6:48 pm  Jun  4, 1989 by bertrand@eiffel.com 
Responses written by Ralph Johnson

>2 - TECHNICAL DIFFERENCES
>-------------------------
>
>Software structure
>
>    Eiffel software is organized in autonomous software units
>(classes), meant to be compiled separately. There is no main program.
>This is what I believe should be the case in object-oriented
>programming. In contrast, I understand that C++ still follows
>the traditional C model. Quoting from Dr. Bjarne Stroustrup's ``The
>C++ Programming Language'' (Addison-Wesley, 1986), which seems to be the
>major reference on C++, page 22, lines 13-14: ``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. Furthermore, reports from
>actual users of C++ seem to indicate a heavy use of ``include files'', a
>technique which I don't fully understand in the C++ context, and which
>has no equivalent in Eiffel.

In practice, C++ is not much different from Eiffel.  Programmers
spend most of their time writing classes.  There are large libraries
of class definitions, each of which is reused in several applications.
It is true that there is a "main program" that creates the objects
of the application program and starts the initial thread of control,
but it is usually very small.  Include files are used to let the
implementation of one class know about the specification of another.
Probably the programming environment carries out this function in Eiffel.

Since C++ is an extension of C, programmers can continue to write
C++ in the C style, and I am sure that many do.  However, they are
missing the point of reusable software and object-oriented programming.

>Assertions
I think that assertions are one of the most attractive things about
Eiffel.  I said this to a more theoretical member of my department,
and he made a snide remark, after which he pointed out that there are
many assertions one might want to make about programs that the Eiffel
assertion language will not let you make.  This is a bogus argument!
Eiffel assertions are a first step to making the theory of software
verification practical.  There can be no doubt that they are much more
powerful than any other assertion method in wide use that provides
more than documentation.  It seems obvious to me that they will help
make software a lot more reliable.

Having said that, I would like to argue with the claim that languages
without assertions cannot support reuse.  There are a lot of ways
to learn how to reuse a class other than looking at the assertions
associated with its functions.  Natural language documentation can
not only do the job as well, but can NEVER be replaced by assertions.
Given the choice of assertions or good comments, I'll choose good
comments.  Of course, there is no reason not to have both.  I think
that we will see assertions become a formal part of more languages.

It is interesting to note that our operating system written in C++
makes heavy use of assertions.  A student implemented assertions
using a macro package.  It would be nice to have them be a part of
the langauge, but they are valuable even with compiler support.

>Exceptions
The Eiffel exception handling scheme is very nice.

>Global variables
Although C++ supports C style global variables, there is no reason
that you have to use them.  In practice, global variables usually
are constant objects, just as in Eiffel.

>Genericity
Another major advantage to Eiffel.

However, C++ isn't as bad as you suggest.  It is possible to use
a macro processor to implement generic classes.  This results
in all the problems of macros, since type-checking errors appear
in the substituted code, not in the original.  The GNU C++
compiler has a set of tools that help make this process as
painless as possible.

It would be better if the language implemented it directly, of course.

>Dynamic binding
This is not that big a deal, either.  Just declare every
(or almost every) function to be virtual.  Only optimize
those parts of a program that are inner loops.

I applaud the Eiffel approach of making the compiler responsible
for finding the most efficient way to implement a program.
One of the bad things that C++ has inherited from C is the
assumption that optimizing compilers are too hard to build
and low-level optimizations are the programmer's responsibility.
This assumption was probably true 20 years ago, but it isn't
true any more.  A good example is having to declare which variables
are stored in registers.  Pointer arithmetic also falls in
this category.

>Consistency of the type system
>Type checking

>    Because of the absence of genericity and the presence of the full C
>type system with its casts and other unsafe mechanisms, C++ cannot be
>reasonably be called a statically typed language. In contrast, Eiffel was
>designed as fully typed.

There is no doubt but that Eiffel's type system is better than that
of C++.  However, in my opinion, C++ is a statically typed language.
It just is not type-safe.  Static type checking just means that the
compiler does the work, not the run-time system.

>Deferred classes
Any C++ class with virtual functions can be a deferred class.
The linker (not the compiler) demands an implementation for each
function, but it is easy to define a function that does nothing
except print an error message.

>Multiple inheritance
Some of us, even outside AT&T, have had multiple inheritance available
for a long time.  In my opinion, multiple inheritance is grossly
overrated.  A good clean design usually eliminates the need for
multiple inheritance.  The main reason that multiple inheritance is
needed is for type-checking.

>Garbage collection

This is both a major advantage and disadvantage.  Would you advise
us writing our operating system in Eiffel instead of C++?  What
impact does your garbage collector have on real-time software?

For years I have told people that C is the world's best assembly language.
Since the Eiffel compiler produces C, I guess you agree.
However, most software should be written in a high-level language.
C++ is better than C, so I suppose that it is now the world's best
assembly language.  There are plenty of cases, such as device drivers,
that require assembly language, something whose performance can be
absolutely predicted from the source code and that lets individual bits
of I/O registers be manipulated.  However, for most software, including
compilers as well as application software, a high-level language is better.

>Automatic recompilation

Experienced Unix programmers can fake something similar with make.
Eventually there will be C++ programming environments, such as
Cynergy, that will do it correctly.

One of the questions that many people have about Eiffel is its
efficiency.  I've made lots of loud remarks about how optimizing
compilers can do a good enough job that there is no need to force
the programmer to have to think about pointers and how a function
call is implemented.  However, is Eiffel an existence proof for
my argument?  Do you have any benchmarks comparing Eiffel and C++?

Ralph Johnson
>Bertrand Meyer