Xref: utzoo comp.lang.eiffel:217 comp.lang.c++:3515
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucsbcsl!eiffel!sarkela
From: sarkela@eiffel.UUCP (John Sarkela)
Newsgroups: comp.lang.eiffel,comp.lang.c++
Subject: Re: Eiffel vs. C++
Summary: response
Message-ID: <148@eiffel.UUCP>
Date: 2 Jun 89 22:09:07 GMT
References: <2689@ssc-vax.UUCP>
Organization: Interactive Software Engineering, Santa Barbara CA
Lines: 49



>  I've been programming in C for about 5 years, and
>just recently started using C++.  I would like to
>start a discussion of Eiffel vs. C++.  I understand
>that both languages use C as a base language, and
>that both implement OOP features, and it seems as
>though the two have much more in common, aside from
>syntactic differences, than they have differences.

First, consider the relative grammatical complexity of the
languages.  Eiffel is an LL(1) language, whereas net
comments seem to suggest that C++ may not even be LALR(1).
Much of the grammatical complexity of C++ seems to derive
from its historical precedents.  The simplicity of the 
Eiffel grammar has much to do with the fact that it does
not attempt to be source compatible with prior languages.
Eiffel, the language, is not C based. The relation which 
Eiffel shares with C is solely that of source language 
to target language.

Second, consider some the features of C++ which Eiffel does 
not possess.  Eiffel does not possess global variables.
Eiffel does not possess pointers. The elimination of 
gratuitous pointer aliasing and extern'ed globals allows a 
smart compiler greater lattitude in generating optimized code.  

Third, consider features of Eiffel which C++ does not possess.
One of the stronger motivations for using object oriented
techniques, is to take advantage of sharing at least specifications
and hopefully implementations.  With untyped object languages such
as Smalltalk this follows naturally.  In the case of statically
typed languages, however, the denotations for collection,
aggregate, or container classes must either be duplicated for
each contained type or or the container must be parameterized
by the contained type.  The Eiffel generic class parameter
language construct directly addresses this issue.  While
ad hoc mechanisms may be used to rewrite nearly duplicate
class declarations in a language which does not support
genericity, IMHO it is perhaps better to put all type
parameterizations within the scope of the language type system. 

Eiffel has included for some time multiple inheritance.  At 
this point in time, I do not have access to a description
of MI in C++.  Given a familiarity with C, however, I expect
that namespace traditions of C could make MI a subtle 
feature of C++ Rev. 2.0.

Finally, consider one of my favorite uses of MI in Eiffel, the
specification class. Given the ability to specify class invariants,
and method pre and post conditions, one can write a specification
class which fully qualifies the domains and ranges of all class
methods. Eiffel provides language hooks which allow straight forward 
specification of these qualities independent of the implementation 
of the components.  One thus may use multiple inheritance to provide 
both a "is-a" categorization of the refined class as well as the 
"code reuse" of implementation inheritance.  I don't have C++
2.0 documentation so I don't know the extent of exception support,
nor do I know the rules for MI in C++, can anyone give a definitive
explanation?  

BTW, can anyone clear up exactly how one specifies the input restrictions
and legitimate outputs of library C++ components?

Conclusion: Eiffel is a grammatically simpler language than C++.
Eiffel does not have many language features that C++ inherited from C.
Eiffel has language support for component specification and qualification.


John Sarkela		sarkela@eiffel.com