Xref: utzoo comp.lang.eiffel:221 comp.lang.c++:3529
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!psuvm.bitnet!uh2
From: UH2@PSUVM.BITNET (Lee Sailer)
Newsgroups: comp.lang.eiffel,comp.lang.c++
Subject: Re: Eiffel vs. C++
Message-ID: <89155.092349UH2@PSUVM>
Date: 4 Jun 89 13:23:49 GMT
References: <2689@ssc-vax.UUCP> <148@eiffel.UUCP>
Organization: Penn State University - Center for Academic Computing
Lines: 64

While I agree with most of this comment, I want to clear up
one possible small understanding.

In article <148@eiffel.UUCP>, sarkela@eiffel.UUCP (John Sarkela) says:
>
>Eiffel does not possess pointers. The elimination of

Lest programmers get the wrong idea, let me say that Eiffel DOES have
a mechanism that allows things to point at one another.  In C (and C++,
I guess) a pointer might be better called an "address".  C is famous for
offering the programmers access to low level machine primitives
such as memory addresses, as you all know.  The probelm is that the
compiler cannot possibly know what the programmer intends to do with
the address, and thus cannot optimize well.  The same argument has
been made about strings---C does NOT have a string type.  We fake it
with pointers (addresses) and arrays (pointers 8-).  In a language
that does have a specific string data type, the compiler writer has
a chance to do some optimization tricks otherwise not available.
>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