Eiffel vs. C++
David Geary
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.
Note that I'd like the discussion to center around
version 2.0 of C++ vs. the most current version of
Eiffel.
I am aware of the fact that Eiffel has a robust
library of base classes, but I would like to see
a discussion of language *features*.
About the only difference that I can discern is the
fact that Bertrand Meyer posts more often to comp.lang
.eiffel than Bjarne Stroustrup posts to comp.lang.c++
;-) ;-)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ David Geary, Boeing Aerospace, Seattle ~
~ "I wish I lived where it *only* rains 364 days a year" ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Adcock
I have heard rumers that there are a lot more problems in general with
compilers for Eiffel than with compilers for C++. Perhaps someone can
illuminate.
> 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.
Both the only compiler for Eiffel and AT&T derived compiler
use C as an intermediate code to compile to. This allows the
actual machine code generation to be performed on a C compiler for a
given machine.
This is different than saying both use C as a base language. C++ syntax
is based on C. Eiffel syntax looks Pascal-like -- at least to my eyes.
So I'd say C++ is to C as Eiffel is to Pascal. I'd expect one's experience
comparing Pascal to C would carry over in comparing Eiffel to C++.
It appears [at least in reading the book] that Eiffel uses at least references
to objects, if not handles, rather than C++'s concept of a "object" being
the actual block of code. So I'd expect C++'s ability to make a object
from other objects would be faster than Eiffel's approach [and Smalltalk's,
and ObjC's, and ...]
The Meyer book raises some interesting points about OOP, and I think it
makes a good addition to one's OOP library, but I'd stay with programming
in C++ -- if one has practical programming tasks to accomplish.
John Sarkela
> 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 sar...@eiffel.com
Bertrand Meyer
>
> I have heard rumers [sic] that there are a lot more problems in general with
> compilers for Eiffel than with compilers for C++. Perhaps someone can
> illuminate.
I'll be straightforward. We, the developers of Eiffel, are fed up
with ``rumers'' and slander. That the proponents of C++ are desperate
for technical arguments is understandable, but does not justify everything.
-- Bertrand Meyer
bert...@eiffel.com
Lee Sailer
one possible small understanding.
In article <1...@eiffel.UUCP>, sar...@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.
Stan Friesen
>
> 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.
>
I may as well put in my two cents worth. My impression is that
Eiffel is a "higher level" language than C++. That is Eiffel is a very
strongly typed OOP language, with a very simple, limited implementation
of objects, whilc C++ is a very flexible language that allows you to
get into the guts of the system when you need to. Thus, as someone else
stated, Eiffel feels like Pascal and C++ feels like C.
Eiffel is very simple syntactically, at the cost of requiring
you to do everything its way. In particular, except for the basic scalar
types, *everything* is a class. There are no seperate derived types,
such as pointers and arrays. A class instance is essentially always a
pointer, but without the ability to do pointer arithmetic, or in fact
anything except allocate, deallocate, and dereference. Thus it acts like
a dynamically allocated instance of an object. (In fact this is what Meyer
would call it, rather than a pointer). Because of this there are a
number of things not possible in the language. For instance the standard
library class ARRAY, used to make array objects via inheritence, had to
be implemented in C and grafted into the language using the "foreign"
language import capability. This limitation is not often important, since
most of the common cases where going outside of Eiffel have been anticipated
and included in the standard library.
C++, on the other hand, is more complex because it allows you to
decide how you want to implement something. It has built in all of the
scalar and derived types from C, thus allowing direct manipulation of
low-level implementation details when necessary. It still has all of the
class features that facilitate OOP. It has dynamic allocation, when needed,
and it allows run-time typing (using virtual functions). But if you don't
need them you don't have to take them.
Thus the trade-off is a simpler, easier to understand language
versus one that gives you more control.
>
> About the only difference that I can discern is the
>fact that Bertrand Meyer posts more often to comp.lang
>.eiffel than Bjarne Stroustrup posts to comp.lang.c++
>;-) ;-)
>
claims to be too busy now. So Andrew Koenig has taken over posting here
for him.
--
Sarima Cardolandion sar...@gryphon.CTS.COM
aka Stanley Friesen rutgers!marque!gryphon!sarima
Sherman Oaks, CA
joh...@p.cs.uiuc.edu
My favorite language is Smalltalk. I also do a lot of C++ programming.
I have never programmed in Eiffel, but I read the book.
Eiffel is a much more elegant language than C++. C++ is more-or-less
upward compatible with C, which is both its greatest strength and its
greatest weakness. C programmers will find it easy to program in C++,
though they might take a while to learn how to use it to best advantage.
Since there are so many C programmers, this means that C++ has a tremendous
marketing advantage. However, if you don't use C then you don't care
about this feature. Instead, you will spend a lot of time wondering
why C++ has this or that feature, with the answer invariably being
for compatibility.
Given the constraint of being an extension to C, I think that C++ is
quite well designed. However, Eiffel does not have those constraints,
and so had a blank slate to solve problems like generic classes, multiple
inheritance, and exceptions. Thus, it is not surprising that it is
quite a bit simpler and yet more powerful.
The first versions of C++ (i.e. the ones we had 3 or 4 years ago) were
fairly unreliable. However, the current C++ compilers are pretty good.
I'm sure that the first versions of Eiffel were also buggy, but there
has been plenty of time to improve it. Eiffel has satisfied users.
I have not seen any decent benchmarks comparing the languages. As a
compiler expert, I don't see any real reason why Eiffel should be more
than 10% slower than C++, though of course I am assuming a reasonably
good compiler.
If you are not a C shop, or if you are unhappy with C, then I would
recommend giving Eiffel a close look. By that I don't mean reading
the book. Instead, buy a copy of the compiler and use it. That is
the best way to learn about a language and to be certain of the
reliability and speed of an implemantation.
On the other hand, if your programmers know and love C then C++ is
the best way to go. You can quickly get them to use the new compiler,
though getting them to exploit all the power of object-oriented
programming will endoubtedly take longer.
Bertrand Meyer
> I would like to start a discussion of Eiffel vs. C++. [...]
> About the only difference that I can discern is
> [joke about compared newsgroup patterns].
Since we often get the question of Eiffel versus C++, Mr. Geary's
initiative provides a welcome opportunity to clarify what I see as the
major differences. I am the main designer of Eiffel, so the following
discussion cannot claim to be that of an independent observer, although it
is certainly honest, and technically correct to the best of my knowledge.
In all likelihood, others will contribute different viewpoints.
I certainly cannot claim to be a C++ expert. If I misrepresent
C++ in any way, it will be by mistake, not design. Should this occur,
someone will certainly correct the mistake, either by writing to me (in
which case I will post the correction if it does turn out that I have
written something wrong) or by posting directly.
This response has three sections: general observations; technical
differences; conceptual differences. I apologize for its length; there is
really a lot to say. Also, there is little new in the material below,
much of which may be found in previous publications about Eiffel; none of
my previous publications, however, has studied Eiffel from the point of
view of a comparison with C++.
Although I believe that the Eiffel environment and tools and the
standard Eiffel libraries provide some of the major arguments for Eiffel,
I will (with two exceptions explained below) limit the discussion to
the languages proper, so as to abide by Mr. Geary's request:
> I am aware of the fact that Eiffel has a robust
> library of base classes, but I would like to see
> a discussion of language *features*
1 - GENERAL OBSERVATIONS
------------------------
Eiffel was designed in 1985, initially not as a language for the rest
of the world, but as an internal tool for a development that Interactive
Software Engineering started at that time. We would have preferred to use
an existing language and environment, but an examination of possibilities,
including C++, quickly showed that nothing was even close to
the minimum required for developing software according to the modern
principles that I (then still a professor at the University of California,
Santa Barbara) was teaching to my students. I did not want to develop a
split personality or to fall into the ``do as I say, not as I do''
syndrome.
I am mentioning this because in a way we had an unfair advantage:
when we started, C++ existed. Although we certainly did not imitate C++,
its very existence was helpful because it showed clearly what
we did *not* want Eiffel to be. In a similar vein, we also looked at Ada,
although in this case the ratio of positive to negative influences
was higher. Even though Ada is not an object-oriented language, its
syntax conventions and its handling of elementary constructs
(expressions, control structures etc.) definitely influenced the
corresponding Eiffel constructs. (By the way, only three languages
did exert a strong semantic influence on Eiffel. One was Simula 67; the
other two were not programming languages but specification languages:
Abrial's Z, in whose design I was somewhat involved around 1978-79,
and my own M, a successor to Z and to this day an unfinished design.
A less important influence was Alphard.)
Finally I do not think that in the long term Eiffel is really
``competing'' with C++. They have almost nothing in common in their aim
and spirit, as explained in the final section of this message.
In my undoubtedly biased view, the real competitor to Eiffel is Ada.
(``Competitor'' for me is a positive word. When you acknowledge
a design as a competitor to yours, it implies respect.)
Ada, as already mentioned, is not truly object-oriented, but its official
charter (reliability, reusability, professional high-quality software
development etc.) is very similar, on paper at least, to that of Eiffel.
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.
Assertions
A fundamental property of Eiffel software is that it may be equipped
with assertions. Assertions are elements of formal specification that
serve to characterize the semantics of classes and their routines
independently of their implementation.
Assertions include in particular routine preconditions (which must be
satisfied when a routine is called), routine postconditions (ensured by
the routine on exit) and class invariants (global consistency conditions
applying to every instance of a class).
Assertions are essential for documenting components.
As a matter of fact, I do not understand how one
can talk about the very idea of reusable software components without
assertions. Using a hardware analogy, a software component without
assertions is similar to, say, an amplifier without precondition
(the acceptable input voltage), postcondition (the gain,
expressed as acceptable ratio of output to input) and invariant
(including for example the temperature limits expected and
maintained by the amplifier). Yet of widely available programming
languages, only Eiffel has these notions.
(A system that does have assertions, and in fact ones that are more
sophisticated than Eiffel's current ones, is David Luckham's Anna system,
developed at Stanford on top of Ada. As far as I know, however, this is
not a deliverable product.)
Beyond their documentation uses, assertions, which optionally
may be monitored at run-time, provide a remarkable debugging and
testing aid. At the recent International Eiffel conference in Paris,
one user organization (Cognos Inc.) reported that
they no longer perform traditional unit testing, having
replaced it by assertion monitoring.
Exceptions
Eiffel has exception handling. Its exception mechanism is original and
I believe it is one of our major contributions, based on the theory of
``Programming by Contract''. As far as I know, there is
no exception mechanism in C++. I believe that one cannot write
serious software without having a way to recover cleanly from unexpected
cases.
Global variables
Consistent with the absence of main program is the absence of
global variables. Global variables are well known to be detrimental to
modularity and more generally to quality. The Eiffel technique
of ``once routines'' is used to ensure disciplined sharing
between classes when needed. (See my column in the Journal of
Object-Oriented Programming, vol. 1, no. 3, pages 73-77,
``Bidding Farewell to Globals''.)
In contrast, C++ seems to support global variables in the C style.
Genericity
Eiffel classes may be generic, i.e. parameterized by types,
as in LIST [T]. Here actual uses of the class may use any type (class)
as actual generic parameter, as in
my_list: LIST [TEXT_LINE]
The genericity may be constrained, as in MATRIX [T -> NUMERIC], which
specifies that actual generic parameters must be descendants, in the sense
of inheritance, of class NUMERIC (equipped with the operations "+", "-",
"*" etc.). Descendants of NUMERIC include (in version 2.2) predefined
types such as INTEGER and REAL. The operations of NUMERIC are available,
within the class, on any variable of type T - so that it can define,
for example, routines for adding and multiplying matrices.
Note that in this example MATRIX itself might inherit from NUMERIC.
Nothing of the sort exists in C++. This means that generic structures
must be simulated by forcing type conversions, or ``casts'', using
low-level C techniques. This defeats any attempt at static typing.
A paper was published not long ago about a proposal for class
parameterization in C++. (Although the paper was published in a refereed
journal, it regrettably did not mention any of the
two object-oriented languages that offer such a facility: Eiffel and
Trellis-Owl, the latter designed by Craig Schaffert and others from DEC).
Since by all reliable accounts the inclusion of such a facility in any
form accessible to C++ users is several years away, it cannot be
considered in any serious discussion. On that kind of time scale one can
promise anything.
Dynamic binding
Dynamic binding is the default mechanism for routine calls in Eiffel
(achieved without any undue effect on performance). The default
policy in C++ is static binding; dynamic binding is only applied to
routines declared as ``virtual''. This may look like an acceptable
requirement to impose on programmers but I believe it is not.
The whole idea of inheritance is that you may reuse a class
later on by writing a descendant and adapting it to new uses
by overriding some of the routines of the original -
within the original semantic constraints, as defined by assertions.
This should be done without impacting the original, which may be
used by many other ``client'' classes. (These concepts are explained
in my book ``Object-Oriented Software Construction, Prentice-Hall, 1988,
as the ``Open-Closed Principle'', section 2.3.) In such a case
the designer of the original routine may have had no inkling whatsoever
that the routine would ever be redefined and subjected
to dynamic binding. This is incompatible with the requirement
that the original designer should have declared the routine
as virtual in the first place.
Instead of forcing the programmer to take care of low-level
optimizations, the Eiffel approach makes the compiler responsible
for exploiting the performance of static over dynamic binding.
The optimizer, working on a set of classes, generates code that applies
static binding to any routine which warrants it (because it is
never redefined).
Performing tedious and potentially dangerous optimizations
in a safe way should be the role of computers, not humans.
In-line expansion
In C++ as in Ada a routine may be declared as ``in-line'', meaning
that calls will be expanded in-line to gain performance. No such mechanism
is available in Eiffel. Contrary to what one might think at first sight, I
believe this to be a serious advantage for Eiffel. As soon as a routine is
declared as in-line, its usefulness is severely limited because it no
longer is a normal routine that can be redefined and
subjected to dynamic binding. The discussion of the previous paragraph
applies even more strongly.
In Eiffel, once again, the corresponding optimizations are performed
by the compiler, not by the human user. The optimizer will automatically
expand certain routines in-line based on systematic criteria beyond
programmer control. One of the criteria is of course that the routine not
be subject to redefinition and dynamic binding; the number of calls in the
code is another.
Again, this seems the safe and efficient approach. Computers can
perform this kind of task both more efficiently and more safely than
humans.
Operator overloading
The term ``operator overloading'' is not entirely adequate since the
issue is whether functions may be assigned names that will be used in
prefix or infix form in calling expressions. This is a syntactic, not
a semantic issue; the more important form of overloading, the semantic one,
is provided in the object-oriented context by redefinition and dynamic
binding.
C++ offers the possibility of using an operator
(from a set of predefined ones) as function name; a similar possibility
is offered in Eiffel 2.2, although it was not present in earlier releases.
So the two languages are indeed comparable in this respect.
Consistency of the type system
Beginning with version 2.2, Eiffel has a fully consistent type system in
which every type, including basic types such as INTEGER, REAL and so on,
is defined by a class (using the multiple inheritance mechanism). This was
made possible by the introduction of the notion of expanded class, of
special BITS M classes (whose instances are bit strings of length M),
and of infix/prefix operators as discussed above. This is achieved without
any effect on the efficiency of dealing with simple values such as
integers, characters and the like. The advantage is mainly a conceptual
one - being able to work with a single set of concepts admitting few
special cases.
There doesn't seem to be anything similar in C++, which uses the C
types as basis.
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.
The present Eiffel compiler misses a small number of type violations
(arising in particular from cases in which polymorphism enables a client
to evade an export or redefinition constraint). These cases seldom arise
in practice, which is not an excuse for not handling them properly. Even
with the current implementation, however, Eiffel is incomparably
more type-safe than C++ because of the presence of genericity,
of the strict enforcement of type checks in assignments,
and of the absence of any unsafe casts or conversions.
Friend functions
C++ has a notion of friend function which, as I understand it, makes
it possible to define routines outside of the object-oriented framework.
There is nothing equivalent in Eiffel. This facility is not missed;
I would see its introduction as a dangerous violation of the object-oriented
principles.
Deferred classes
An extremely important notion in Eiffel is that of deferred class,
which describes a non-fully-implemented abstraction. Deferred classes
are used to capture commonalities and are central to the object-oriented
approach. Two aspects are particularly important: the ability to define a
partially deferred class, which contains both implemented and
non-implemented routines; and the ability to attach assertions to a
deferred class and its deferred routines, and thus to specify
the behavior of yet to be implemented software.
C++ as described in published references does not appear to support a
similar notion. I have heard, however, that the forthcoming version of
C++ has a notion of abstract class, which is meant to play the same role.
Perhaps someone will describe this facility in detail so that readers
can judge.
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.)
The published references on C++ systems exclude multiple inheritance
which, however, is rumored to be imminent. I must confess
this is one aspect on which we, at Interactive Software Engineering, are
rather touchy. The first time I personally heard about the ``imminence''
of multiple inheritance in C++ was November of 1986. Since then, that is
to say for two years and a half, we have essentially been unable
to use the presence of multiple inheritance as an
argument for Eiffel - so successful have others been in persuading almost
everyone that multiple inheritance in C++ was around the corner. Here I
would like to appeal to developers of software tools and
suggest a universal ethical rule: whenever you refer to a feature that is
not yet available in the released distribution of your product, mention it
unambiguously in every relevant publication, together with
an estimated date of availability (to the public, not internally).
The name for such a policy is simple: honesty.
This being said, it is indeed possible that multiple inheritance
will become available in C++ during my lifetime. It is not clear
from what I have read and heard that the non-trivial problems of
multiple inheritance, such as name clashes, have been properly addressed.
(If I am wrong on this, please enlighten me.)
Renaming
Eiffel offers a powerful technique in connection with inheritance:
renaming. A class can rename inherited routines and attributes
(i.e. methods and attribute variables for those who prefer such terms).
This is used for removing name clashes in multiple inheritance and also,
perhaps even more importantly, to provide locally adapted terminology
when you inherit the right features but under the wrong names. As
discussed in my OOSC book referenced above (section 10.4.7) and in a JOOP
column (Vol. 1, no. 4, pages 48-53), this is essential if inheritance is
to provide support for reusability in a practical industrial context.
Garbage collection
This item and the next violate Mr. Geary's request to limit the
discussion to language features. I have included them anyhow because,
even though they are environment rather than language features,
they are made possible or next-to-impossible by the language design.
To write serious object-oriented software, which at run time will
inevitably generate many objects, some of which may become useless,
one needs a good garbage collector. This is the case in Eiffel
(which uses an incremental, parallel scheme so as not to impair performance).
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.
Automatic recompilation
One of the most important practical aspects of Eiffel is the automatic
compilation mechanism, based on automatic analysis of inter-class
dependencies (multiple inheritance and client). This removes the need for
make files and include files. Although I recall some seemingly interminable
notes on the feasibility (or lack thereof) of a similar mechanism in
comp.lang.c++, I don't know of any implemented mechanism for C++.
Again, this seems due to the very design of the language; and again,
the difference seems to result from irreconcilable views of what should be
done by computers and what should be the province of humans. The Eiffel view is
that error-prone and tedious management tasks should be handled by tools,
and that programmers should concentrate on solving programming problems.
Pointer arithmetic etc.
One of my major objections to C++ stems from what that language has
rather than what it has not. Because C++ retains almost total
compatibility with C, it keeps all its low-level and dangerous features.
The design of C dates back to the late sixties and is obsolete
by modern software engineering standards.
Compatibility with C means that in C++ you still have pointers,
type casts, pointer arithmetic, function pointers, malloc, free, bizarre
operator precedence (the famous asterisk/parenthesis bugs),
weak type checking and so on.
I strongly disagree with this approach if the goal is to obtain software
quality. Take pointer arithmetic, for example. I would contend that you can
have quality software, or you can have pointer arithmetic; but you cannot
have both.
In Eiffel, the choice has been made. None of these low-level features
are present (as John Sarkela pointed out in a previous message); needless
to say, they are not missed.
Compatibility with C software
C++ is obviously very compatible with C. But in Eiffel too you can
easily communicate with C software; both call-in and call-out are
provided. This makes it possible to reuse existing software easily.
The need for such communication was not, however, deemed to be a good
argument for impairing the consistency of the language itself.
Simplicity and ease of learning
Much of the plea for C++ is based on the observation that it provides
an easy transition from C, which (for better or worse) is the language
many programmers know nowadays. Using Dr. Brad Cox's expression (meant
for Objective-C), this supports an ``evolutionary'' approach.
I can certainly respect this view and its appeal to software managers
in industry. But I believe that by considering it more closely one will
find it short-sighted and ill-founded.
Learning a new language such as Eiffel is nothing for a
competent programmer. For Eiffel, which is small and simple,
the learning process typically lasts a few days at most.
Nobody has ever told us that Eiffel was difficult to learn.
(If you read this, have tried to learn Eiffel,
and found otherwise, please respond!) I believe that the process of
going to Eiffel is in fact much smoother, as you don't have to use
a confusing mix of old and new concepts.
In a language that you master totally, you feel
confident and you can concentrate on your job rather than on
the language intricacies.
Also, the brief initial shock produced by the realization that you
cannot easily write your programs in a traditional way any more is,
in the experience reported by Eiffel users, highly salutary.
3 - CONCEPTUAL DIFFERENCES
--------------------------
The considerable differences listed above more than offset, in my mind,
any similarity that may seem to exist between Eiffel and C++.
Beyond these individual technical differences, the contrast between
the two languages is deep and conceptual. Eiffel is a new
language and environment designed with a precise charter
(enabling the production of very high quality software by professional
programmers). C++, as I see it, is an attempt at a more modern version of C.
(The basic C++ reference quoted above, in its ``historical note'' on page 5,
writes that ``the difference between C and C++ is primarily in
the degree of emphasis on types and structures'') .
There are undoubtedly arguments for both approaches. Needless to say,
I find the arguments for the first to be stronger.
--------------------
This is probably overkill already and I shall resist the temptation to
go on. Have I at least succeeded in convincing Mr. Geary that the technical
differences are deep ones?
In all likelihood, this note, prompted by Mr. Geary's question,
will eventually be rewritten as a short article, so that comments and
criticism will be greatly appreciated.
-- Bertrand Meyer
bert...@eiffel.com
Bertrand Meyer
``Ia pamiatnik siebie vosdvig nierukotvornyi...''
Aleksandr Pushkin
``A la septieme fois, les murailles tomberent.''
Victor Hugo
``Eppur si muove.''
Galileo Galilei
``You can fool, etc.''
Abraham Lincoln
From message <26...@ssc-vax.UUCP> by d...@ssc-vax.UUCP (David Geary):
> I would like to start a discussion of Eiffel vs. C++.
A previous note described my view of the differences between the
two languages. There is another side to the story, however.
Mr. Geary's message painfully reminded me that the kind of
comparative discussion he calls for
(a desire many other people undoubtedly share)
should normally have been held live next October in a public forum.
At the 1988 edition of OOPSLA (the ACM conference on
object-oriented programming), a well-known and respected
Professor from a university on the East Coast invited me
to participate in a panel at the next conference
(New Orleans, early October 1989). The idea for the panel was
to discuss the designs of major object-oriented languages, with
the Eiffel, Smalltalk, C++ and Objective-C viewpoints presented
respectively by myself, Dr. Adele Goldberg from ParcPlace, Dr. Bjarne
Stroustrup from AT&T and Dr. Brad Cox from Stepstone. This looked liked a
great idea and I agreed immediately.
Some time later I was told that I was out of the panel. The reason:
Dr. Stroustrup had declared that he would not participate if I did.
Perhaps even more stunning than Dr. Stroustrup's reaction was the panel
organizer's apparent inference that, if A refuses to be on a panel with B
(who himself welcomes the opportunity), then B should be excluded.
Then as now I did not understand why the inference is not that A must be
taken to his word.
I do not know the current status of the panel proposal and
have not been contacted again for that panel. A letter and an e-mail
message to the organizer remained unanswered. Clearly there will be
no opportunity for attendees of OOPSLA '89 to hear about
the comparative designs of Eiffel and C++.
In a way, this whole story confirms that we must be doing
something right. If the developer of C++, backed by the immense
resources of one of the largest and richest companies in the world,
by constant one-sided propaganda in the technical media, by a strong
position in the organization of OOPSLA, and by countless
other assets having to do with the sheer size and wealth of
the supporting organization, can find no better argument
to defend C++ than exclusion of any reference to Eiffel in public forums,
then he must be rather scared indeed.
There is no doubt that censorship of this nature will have damaging
immediate effects on the recognition of Eiffel's contribution to the
cause of software engineering. The history of such cases over the past
three years amply demonstrates this. But it is a folly to believe that
good ideas can be suppressed for very long. Many people,
some of whom were quoted at the beginning of this note,
have said it much better than I ever could.
Money, power and intimidation cannot buy everything. Once the lights
are out, the hype is gone, the pre-settled panels have been held and
the biased articles have been read, sooner or later people will go
home and start to work. Then they will judge on costs and benefits,
not promises and politics.
Among the readers of comp.lang.c++, there are two non-disjoint
groups whose reaction to the present situation is of particular interest.
One is AT&T's employees and particularly its researchers, whose contributions
to computing science have been so impressive over the past 30 years.
Blaming a large organization for the individual behavior of each of
its workers would be unfair and stupid. But when the misdirected
efforts of one or more employees of a multi-billion dollar company
leave the (right or wrong) impression that the company is trying
to crush a group of independent, free-spirited scientists, simply
because they have had another idea and work hard to push it -
I doubt their colleagues feel very proud.
The other group is C++ users and enthusiasts. Many of them undoubtedly
love C++ for highly respectable reasons and neither I nor anyone else
may ever be able to convince them that Eiffel is better for what they do.
Having everyone agree on any single topic, even if it is just the
programming language - what a horrible prospect! But regardless
of any difference in technical opinions, I would be surprised if
they did not keep open minds. Am I wrong in assuming that they, too,
want to base their decisions on rational arguments clearly expressed,
not on the autocratic suppression of alternative approaches?
-- Bertrand Meyer
bert...@eiffel.com
Bjarne Stroustrup
Bertrand Meyer, president of Interactive Software Engineering, the
supplier of Eiffel, is correct on one point: I did refuse to appear on
a panel with him. My reasons are personal. He has insulted my friends
and colleagues in public; he has attacked me in public and in private;
he has misrepresented and maligned my technical work; his company's
advertising has quoted me out of context and without permission.
Technical discussion requires more common courtesy and more detachment
from commercial concerns.
Meyer complains about censorship, money, power, and intimidation.
There is no censorship and no conspiracy against him, his company, or
his language; the very notion is ridiculous. In fact, it is evident
that ISE's marketing budget for Eiffel vastly exceeds AT&T's minimal
marketing budget for C++ (not a cent of which is spent attacking
anyone).
As to the merits of Eiffel, C++, or any other language, users will
decide. Comp.lang is for programmers, not corporate paranoia.
Bob Weiner
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.
This may true but many applications, especially real-time projects that
need the power of testable pre and post conditions, also need pointer
access to get at underlying hardware tied to different signal lines.
Alternatively, an environment that fully encapsulates the hardware
interface has to be provided.
Does this mean that inline assembler will never be supported in Eiffel?
I've read that the language is meant to interface well with external
programs and possibly modules. Can I link C or C++ object files into an
Eiffel application?
Are there any plans to support cross-compilers, e.g. licensing of Eiffel
to third parties with experience in cross-compiler development, or any
support for real-time, embedded applications? You are competing with
Ada as a development environment, aren't you?
--
Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner
(407) 738-2087
Larry Morris
>
> Finally I do not think that in the long term Eiffel is really
> ``competing'' with C++. They have almost nothing in common in their aim
> and spirit, as explained in the final section of this message.
> In my undoubtedly biased view, the real competitor to Eiffel is Ada.
> (``Competitor'' for me is a positive word. When you acknowledge
> a design as a competitor to yours, it implies respect.)
> Ada, as already mentioned, is not truly object-oriented, but its official
> charter (reliability, reusability, professional high-quality software
> development etc.) is very similar, on paper at least, to that of Eiffel.
>
is radically different from C++, and more modern in its design. Ada, from
what I've seen, is used more by mandate than choice [not that it's a
particularly "bad" language, but I'd be willing to bet that nearly all
new engineering users of Ada have a DoD standard on their desks].
Setting up Ada as the "competition" seems like a strawman to me.
As for the "charter" of C++, was it intended for unreliable, one-time,
amateur, poor-quality software development? I doubt that Stroustrup's
intent was significantly different than yours. I see C++, Objective-C and
Smalltalk as Eiffel's most obvious competitors for the engineering
marketplace, as much for political as design considerations. Ada is likely
to remain comfortably entrenched in its own well-protected market.
> can talk about the very idea of reusable software components without
> assertions...
> maintained by the amplifier). Yet of widely available programming
> languages, only Eiffel has these notions.
Assertion checkers, of course, have been used for years as tools outside
the scope of the language, as libraries, or extracted by tools from
code comments. Placing assertions within classes as part of the language
is, I must agree, a very powerful feature. But Eiffel's design philosophy
calls on programmers to define their classes with assertions in addition
to coding their implementation; something most programmers aren't used to
doing and may view as an onerous task. Since assertion checking isn't any
better than the assertions dreamed up by the programmer, I'm skeptical of
using it to "replace" unit testing.
>
> Eiffel has exception handling. Its exception mechanism is original and
> I believe it is one of our major contributions, based on the theory of
> ``Programming by Contract''. As far as I know, there is
> no exception mechanism in C++. I believe that one cannot write
> serious software without having a way to recover cleanly from unexpected
> cases.
>
I agree 100% with this, and I view it as the single biggest selling point
of Eiffel over C++.
>
> In C++ as in Ada a routine may be declared as ``in-line'', meaning
> that calls will be expanded in-line to gain performance. No such mechanism
> is available in Eiffel....
> The optimizer will automatically
> expand certain routines in-line based on systematic criteria beyond
> programmer control...
>
I'm a bit skeptical about this approach. In data communications software
(or other types of real-time software) it's frequently necessary to optimize
certain methods heavily. I'd like some choice over this without having to
resort to an assembly language or C call-out. How many times must I reference
the method before your optimizer decides to inline it? How many lines may I
add to the method before your approach changes? By adding a line, will I
speed things up or slow them down?
>
> To write serious object-oriented software, which at run time will
> inevitably generate many objects, some of which may become useless,
> one needs a good garbage collector. This is the case in Eiffel
> (which uses an incremental, parallel scheme so as not to impair performance).
> 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.
Obviously, one does not need a good garbage collector if one cleans up
after oneself. Having been burned before by garbage collection, I remain
wary of claims of efficiency. With C++, I control allocation and deallocation
of memory resources explicitly, so I know their performance impact. With
Eiffel, do I just trust that you won't collect garbage at an inopportune
time, like halfway through emitting a frame?
> Compatibility with C means that in C++ you still have pointers,
> type casts, pointer arithmetic, function pointers, malloc, free, bizarre
> operator precedence (the famous asterisk/parenthesis bugs),
> weak type checking and so on.
> In Eiffel, the choice has been made. None of these low-level features
> are present (as John Sarkela pointed out in a previous message); needless
> to say, they are not missed.
In analyzing incoming data frames, we freqently encounter the problem of
extracting or adding variable-length headers, at various positions in a
byte array. It's most convenient (and efficient) to be able to adjust a byte
pointer, then reinterpret the pointer as a struct pointer. This may not be
"textbook" programming style, but life isn't filled with textbook problems
either. The pragmatism of C in these situations is one reason I prefer it to
Pascal these days, and why I endure all of C's warts. Yes, I want many of
the benefits of Eiffel...but when I need just to get the job done, will I
be calling my old C routines because your choices didn't fit?
> Learning a new language such as Eiffel is nothing for a
> competent programmer. For Eiffel, which is small and simple,
> the learning process typically lasts a few days at most.
Natch! I learned C in a few days, few being a relative term. Becoming fully
versed and competent took a "few" more, and I might still have a couple days
to go.
You're probably right about being easier to learn than C++, though, not
having the forward interference from C to contend with.
As someone involved in the selection of an OOP language, I have to say that
the decision between C++ and Eiffel isn't a trivial one. Many of the factors
are political, since C++ has a large and "grass-roots" support base, while
Eiffel is relatively new to the scene, and more academic in its "feel." I
think the decision will be influenced strongly by support tools, since
successful OOP programming, IMHO, depends on making classes available to
a team in an accessible and controllable manner. Eiffel has a solid, but
largely proprietary, environment set; C++ seems bogged down in this area,
but with many vendors interested.
I hope both ISE and AT&T feel some healthy competition between their products,
since this will encourage more tool development. These days a language can't
be considered realistically outside of its tool environment; this goes double
for an OOP language.
Larry Morris, Tridom Corporation
...!emory!tridom!lam
Ron Guilmette
>From article <659...@hplsla.HP.COM> by ji...@hplsla.HP.COM (Jim Adcock):
>>
>> I have heard rumers [sic] that there are a lot more problems in general with
>> compilers for Eiffel than with compilers for C++. Perhaps someone can
>> illuminate.
First, make that "compiler" not "compilers". I believe that there is only
one. That number is only two less than the number of C++ compilers, but
it is worth noting if you are like a paranoid hardware manufacturer and
you want to be assured of a second source.
I had the opportunity to play with Eiffel for awhile once about two
years ago. The compiler was just fine, even then. It is probably
even better now. Nonetheless, I'm playing C++ these dayz and I'm
glad. Even though the Eiffel compiler was fine, I didn't much like
that language itself. Now I don't want to get into an argument with
Bertrand or anybody else about it. It is just a matter of personal
taste. "Each to his own" I say. Let every man choose his own tools
For me, Eiffel was kind of like a chastity belt. It definitely keeps
you "pure" but you will probably have less fun. :-)
--
// Ron Guilmette - MCC - Experimental Systems Kit Project
// 3500 West Balcones Center Drive, Austin, TX 78759 - (512)338-3740
// ARPA: r...@mcc.com
// UUCP: {rutgers,uunet,gatech,ames,pyramid}!cs.utexas.edu!pp!rfg
Andrew Ormsby
>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.
It is true that current implementations of Eiffel use C as a base
language. With Eiffel, however, the use of C is really as a portable
assembler that the Eiffel translator can compile into. This has
presumably greatly reduced the development costs of the compiler for
Interactive Software Engineering, Meyer's firm. There is the added
advantage that it enables them to make use of the machine dependent
optimisers that are usually part of the C compilation systems on
various machines. However, I would contend that the fact that Eiffel
uses C as a "base language" is only an implementation detail.
C++ is very different. To quote Stroustrup in the introduction to the
C++ book, "Except for minor details, C++ is a superset of the C
programming language". C++, quite deliberately, therefore ends up
looking very much like C.
While most current C++ translators are implemented as preprocessors
for C compilers, there are a growing number of true C++ compilers.
My view is that C++ is what people should be using as an alternative
for C in applications where C was really necessary; where there are
programmers around who know how to use it properly. My worry is that
C++'s additional complexity over and above C will make it even more
likely that bad C++ programs are written. Eiffel may be more
appropriate as a general purpose language; my personal opinion is that
it looks likely to be less easily misused. However, C++ is widely
available and cheap. Eiffel is less widely available and rather
expensive. Its a shame.
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>~ David Geary, Boeing Aerospace, Seattle ~
>~ "I wish I lived where it *only* rains 364 days a year" ~
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Andy Ormsby, a...@cs.aber.ac.uk
Department of Computer Science, aro%cs.abe...@nsf-relay.ac.uk
University College of Wales, aro%cs.abe...@ukacrl.bitnet
Aberystwyth, Dyfed, UK, SY23 3BZ.
M.Gardi - ICR
I have heard that eiffel creates hideously large executables from very
trivial programs. Does anyone have any information as to whether this is
true or not?? I found that using advantage C++ also produced large
executables...one of the reason why I am using Zortech C_++ currently. It does
not seem to have this problem (executable size seems on average to be about
1/5 the size of advantage c++ code).
We're talking 35K here for a hello world program in advantage...something
that can't be tolerated on the PC. One source gave the comparable eiffel
program a number even much higher.
Peter DeVries
Mutual Life of Canada (519) 888-2957
c/o mgardi@watdcsu
James W. Gish
In article <1...@eiffel.UUCP> Bertrand Meyer writes:
> C++ is obviously very compatible with C. But in Eiffel too you can
>easily communicate with C software; both call-in and call-out are
>provided. This makes it possible to reuse existing software easily.
>The need for such communication was not, however, deemed to be a good
>argument for impairing the consistency of the language itself.
>
I believe this should be qualified somewhat. You indeed can make
calls to C routines from Eiffel and vice versa. But life is rarely
that simple. You have to map Eiffel objects to C structures and vice
versa. This is tedious but can be done in some/most(?) cases. One of
the biggest problems that keeps calls from Eiffel to C non-trivial is
the inability to use C include files within Eiffel for the definition
of types on the Eiffel side. This is a serious obstacle to making use
of much C code. A case in point is the use of X. (There are other
problems here such as callbacks, but I don't want to go into that
here). Much of the X stuff is defined in C header files. To make use
of these header files within Eiffel requires either a manual or
user-defined automatic translation mechanism.
I don't expect miracles here and I don't expect ISE to come up with
solutions to the problems generated by C language design sins or the
poor coding practice of some C programmers, I just want to point out
that the statement "...in Eiffel too you can easily communicate with C
software; both call-in and call-out are provided" does not tell the
whole story.
Also, with respect to reusing existing software easily, it definitely
is NOT easy to make use of existing X code, particulary existing
widgets. We've made a serious attempt at it and can do it with some
success, but it is not fun or easy. And please correct me if I'm
wrong, but having the X-based graphics classes will not make it any
easier to (re)use existing widget sets either.
>
>Simplicity and ease of learning
>
> Much of the plea for C++ is based on the observation that it provides
>an easy transition from C, which (for better or worse) is the language
>many programmers know nowadays. Using Dr. Brad Cox's expression (meant
>for Objective-C), this supports an ``evolutionary'' approach.
>
> I can certainly respect this view and its appeal to software managers
>in industry. But I believe that by considering it more closely one will
>find it short-sighted and ill-founded.
>
> Learning a new language such as Eiffel is nothing for a
>competent programmer. For Eiffel, which is small and simple,
>the learning process typically lasts a few days at most.
>Nobody has ever told us that Eiffel was difficult to learn.
>(If you read this, have tried to learn Eiffel,
>and found otherwise, please respond!) I believe that the process of
>going to Eiffel is in fact much smoother, as you don't have to use
>a confusing mix of old and new concepts.
>In a language that you master totally, you feel
>confident and you can concentrate on your job rather than on
>the language intricacies.
I agree that learning a new language is nothing for a competent
programmer. However to learn to program effectively and efficiently
in a new language takes much more than a few days, especially if one
is switching paradigms. Learning to use the language fully and
understand its subtleties is a long term affair. I have been using
Eiffel for several months and still don't feel like an expert - nor
did I expect that I would.
One of the obstacles to learning is the lack of a comprehensive
language reference manual. I was pleased to read that one is
forthcoming. Another obstacle, which I believe another poster already
stated, is the lack of thorough documentation for the library classes.
At times, I have had to write test programs or actually look at the
source code for the classes to figure out how to use them.
A case in point is the class H_TABLE. I wanted to dump the non-null
entries of a an H_TABLE that I created. I thought that I could loop
through it using entry(i) with i going from 0 to nb_elements-1.
Unfortunately, it wasn't that simple, since entry(i) doesn't return
the non-null entries like I expected it would. Better documentation
would have prevented me from making this mistake. Examples in the
documentation could alleviate some of the confusion.
>
> Also, the brief initial shock produced by the realization that you
>cannot easily write your programs in a traditional way any more is,
>in the experience reported by Eiffel users, highly salutary.
>
But still requires a considerable realignment of ones neurons :-)
--
Jim Gish
GTE Laboratories, Inc., Waltham, MA
CSNET: jg...@gte.com UUCP: ..!harvard!bunny!jwg1
Stan Switzer
> If you are not a C shop, or if you are unhappy with C, then I would
> recommend giving Eiffel a close look. By that I don't mean reading
> the book. Instead, buy a copy of the compiler and use it. That is
> the best way to learn about a language and to be certain of the
> reliability and speed of an implemantation.
If, on the other hand, you ARE a C shop and are happy with C, then I
would recommend giving Eiffel a close look. By that I don't mean
buying and using the compiler. Instead, buy a copy of the book and
read it.
It never hurts to take a look at other ideas. Although I find the
syntax a bit tedious, Eiffel is an exceptionally well-thought-out
language design.
Stan Switzer s...@ctt.bellcore.com
"Plagiarism is the sincerest form of imitation."
joh...@p.cs.uiuc.edu
> Written 6:48 pm Jun 4, 1989 by bert...@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
Jim Adcock
> > compilers for Eiffel than with compilers for C++. Perhaps someone can
> > illuminate.
>
> with ``rumers'' and slander. That the proponents of C++ are desperate
> for technical arguments is understandable, but does not justify everything.
Well, for what its worth, the "rumers" I was talking about can from people
who are evaluating a wide variety of OOPLs -- not C++ "proponents" or
vendors. People who consistently read this notes string know I am less
than totally enamored of the quality of C++ compilers too. But, I am
convinced that C++ compilers are now good enough to do serious
commercial work.
Since I was unable to verify these Eiffel problems myself [not having an Eiffel
compiler], I labeled them "rumors."
I don't know about "slander", but I do think Meyer could have presented a
more honest portrayal of C++ than presented in his book. Still, I think
he presents some interesting OOP points, if one is able to filter out all
the dogma.
Henry Spencer
>For me, Eiffel was kind of like a chastity belt. It definitely keeps
>you "pure" but you will probably have less fun. :-)
It struck me, in fact, that a good many of Dr. Meyer's comparisons between
C++ and Eiffel boiled down to "C++ lets the programmer foul things up in
any way he pleases, while Eiffel insists on doing it right". This is, in
fact, a long-standing philosophical difference between the C camp and the
Pascal camp. C has always given you more than enough rope to hang yourself
with, which means that writing clean, well-behaved programs in C requires
competence, experience, and strict self-discipline... qualities that are
all too rare in the real world. On the other hand, all that rope can be
quite useful when the problem to be tamed is large and obstreperous. The
Pascal side favors using the language to impose discipline, which makes it
a LOT easier to get reliable, well-behaved programs but can make it harder
to get the desired results with those programs. Which set of tradeoffs is
better depends on the circumstances and the people.
(Me? I find the Pascal theory very attractive but at the moment am fully
in the C camp for pragmatic reasons. Combining the virtues of the two
ought not to be impossible but seems to be difficult in practice. Perhaps
a mixed approach is better than trying to pick one or the other.)
--
You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology
but it's not worth it. -Collyer| uunet!attcan!utzoo!henry he...@zoo.toronto.edu
James W. Gish
The following "Hello world" program generated an executable on a Sun3
of 147456 bytes:
class world
inherit
STD_FILES
feature
Create is
do
putstring( "Hello world." ); new_line;
end;
end
The .eiffel file used was:
------------ EIFFEL SYSTEM DESCRIPTION FILE -------------------
-- For simple uses, just replace ``root_class_name'' below
-- by the name of the root class of your system (lower case)
ROOT: world
SOURCE: /usr/proj126/Eiffel/library
EXTERNAL:
NO_ASSERTION_CHECK (N):
PRECONDITIONS (N):
ALL_ASSERTIONS (Y):
DEBUG (N):
TRACE (N):
OPTIMIZE (N):
GARBAGE_COLLECTION (N)
VIRTUAL_MEMORY (N)
C_PACKAGE (N):
C_EXTERNAL:
MAKE:
VISIBLE (N):
----------------------------------------------------------------
Scott Schwartz
>(Me? I find the Pascal theory very attractive but at the moment am fully
>in the C camp for pragmatic reasons. Combining the virtues of the two
>ought not to be impossible but seems to be difficult in practice. Perhaps
>a mixed approach is better than trying to pick one or the other.)
Isn't this what Turing Plus tries to do?
--
Scott Schwartz <schw...@shire.cs.psu.edu>
Bertrand Meyer
La calunnia: e` un venticello,
Un auretta assai gentile
che insensibile, sottile
incomincia, incomincia susurrar.
(The great Calumny aria from the Barber of Seville)
I have never had any personal business with Dr. Stroustrup.
Any personal hostility is his problem.
I let readers judge who is insulting whom. For my part,
I have no time to waste on his personal attacks, not a single one
of which is true.
In my previous message, I stated a fact: Eiffel has been
excluded from a projected OOPSLA panel on the design of object-oriented
languages. This is in the public record and now confirmed by
the party that caused the exclusion. Anyone can judge on the ethics
of the situation.
------------------------
Note: I am writing this just before leaving for a 3-week trip and I cannot
possibly answer the mail messages that I have received recently.
I will try to do so when I come back. I thank all the people who
wrote to me. A few of these messages disagreed on some points
of my technical note, although in my quick review I didn't find
anything that clearly invalidated something I wrote.
Several people mentioned that I should have included Turing among
the ``commonly available languages'' supporting assertions. I guess
I was not aware that Turing was so commonly available in
universities. In any case I am happy to correct the omission and
to admit that my Turing could benefit from some brushing up.
--
-- Bertrand Meyer
bert...@eiffel.com
benveniste marc,lsp
>
> My favorite language is Smalltalk. I also do a lot of C++ programming.
> I have never programmed in Eiffel, but I read the book.
>
> Eiffel is a much more elegant language than C++. C++ is more-or-less
> upward compatible with C, which is both its greatest strength and its
> greatest weakness. C programmers will find it easy to program in C++,
> though they might take a while to learn how to use it to best advantage.
> Since there are so many C programmers, this means that C++ has a tremendous
> marketing advantage.
Although It may sound anachronistic and/or idealistic, I believe that
programming languages should be chosen based on criteria such as security
(in its wider sense), reliability, extensibility, readability etc. rather
than by its marketing advantage or upwards compatibility with widespread
traditions.
We surely don't want to reinvent the wheel, but we can't let an inadequate
component flaw a design just because everybody likes it and works with it;
we would be trapped in a vicious circle.
Disclaimer: No affiliation... except, perhaps, candidness.
Henry Spencer
>>(Me? I find the Pascal theory very attractive but at the moment am fully
>>in the C camp for pragmatic reasons. Combining the virtues of the two
>>ought not to be impossible but seems to be difficult in practice. Perhaps
>>a mixed approach is better than trying to pick one or the other.)
>
>Isn't this what Turing Plus tries to do?
There are several languages that try to provide a "safe" subset and a more
powerful version that can be used only in "unsafe" modules. (It's been a
long time since I read about Turing Plus, but that's my vague memory of it;
certainly this is Modula 3's approach.) There are two problems with this.
First, restrictions on how unsafe code can be used are common (e.g. one
must call a function to get at it). Second, the unsafe language is
seldom anywhere near as powerful as, say, C -- it's usually the safe
language with a few minimal, grudgingly-provided extensions. Things like
pointer arithmetic, for example, are seldom directly available. The usual
result is that it's easier to just write the unsafe parts in C and call
them. You're going to have the function-call overhead anyway.
That is what I meant by a mixed approach (as opposed to a combination):
admit that you want two different languages, not a Dr.Jekyll/Mr.Hyde
combination, and concentrate on clean interfaces and fast interlanguage
calls.
Don Ahn
>
>I have heard that eiffel creates hideously large executables from very
>trivial programs. Does anyone have any information as to whether this is
>true or not?? I found that using advantage C++ also produced large
>executables...one of the reason why I am using Zortech C_++ currently. It does
>not seem to have this problem (executable size seems on average to be about
>1/5 the size of advantage c++ code).
>We're talking 35K here for a hello world program in advantage...something
>that can't be tolerated on the PC. One source gave the comparable eiffel
>program a number even much higher.
What I'd be more interested in here is the INCREMENTAL increase in executable
size due to program lines/functionality. Given the fact that eiffel has more
functionality in it's run-time environment (built in garbage collection etc..)
it is understandable that for "trivial" programs code size will seem to be
unexplainably huge.
This is not to say that the code size for a "hello, world\n" program is not
completely unimportant. A extremely large amount of code for a "trivial"
program may indicate an inefficient linker. But it does not necessary
mean that the compiler is a dog.
A more meaningful comparison to me would be the executable size of two large
"algorithmically equivalent" programs. Given the power that an OOPS gives
you, re-useable and organized code, it may be possible to DECREASE your
executable size over a non-OOPS language for large programs. Of course, a
well implemented program in a lower-level language (C , assembler) will always
be more efficient than an OOPS. The problem is, it gets exponentially harder
to create a "well implemented" program as its size goes up in a low level
language.
As I see it, OOPS was created to help make LARGE programs maintainable.
The merits of an OOPS should be measured in this realm.
Jos Warmer
> Although It may sound anachronistic and/or idealistic, I believe that
>programming languages should be chosen based on criteria such as security
>(in its wider sense), reliability, extensibility, readability etc. rather
>than by its marketing advantage or upwards compatibility with widespread
>traditions.
> We surely don't want to reinvent the wheel, but we can't let an inadequate
>component flaw a design just because everybody likes it and works with it;
>we would be trapped in a vicious circle.
This is wishfull thinking. These kind of choices are almost *never* made
on the right criteria. People tend to be very conservative.
Jos Warmer
j...@cs.vu.nl
...uunet!mcvax!cs.vu.nl!jos
--
Jos Warmer
j...@cs.vu.nl
...uunet!mcvax!cs.vu.nl!jos
Jos Warmer
>
>The following "Hello world" program generated an executable on a Sun3
>of 147456 bytes:
>The .eiffel file used was:
>
>C_PACKAGE (N):
The size of executables in Eiffel depends very much on the compile options.
The smallest size will be reached when all assertions are turned off.
And all optimizations like inline functions and others are only done
when generating a C package. Using:
ALL_ASSERTIONS(N): ALL
C_PACKAGE (Y): C
gives an executable of 73728 bytes. Using `strip world' gives 57344 bytes.
(Eiffel Version 2.1b, SUN3.5)
Besides, I do agree with Don Ahn:
In article <25...@agate.BERKELEY.EDU> don...@gypsum.berkeley.edu (Don Ahn) writes:
>
>What I'd be more interested in here is the INCREMENTAL increase in executable
>size due to program lines/functionality. Given the fact that eiffel has more
>functionality in it's run-time environment (built in garbage collection etc..)
>it is understandable that for "trivial" programs code size will seem to be
>unexplainably huge.
...
Marshall Cline
[...deleted stuff...]
>I think that assertions are one of the most attractive things about
>Eiffel...
>Eiffel assertions are a first step to making the theory of software
>verification practical... It seems obvious to me that they will help
>make software a lot more reliable.
>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... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^
More more more. I'm salivating thinking about it. Do you mean that the
grad student simply created a standard way to state assertions? Are they
(the assertions) usable in any formal way? Ie: Do you sometimes expand
them into:
#define assertion(bool_expr) if (!(bool_expr)) print_nasty_msg()
Or do you have tools that formally check method correctness which use the
assertions as constraints???
More more more. Tell me more!
Seriously: I'm interested in this line of thought, being that I have a
software engineering bent. Given the flavor of this newsgroup, perhaps
others would be interested as well. Waddayasay? Wanna post the macros?
Cheers.
Marshall
--
________________________________________________________________
Marshall P. Cline ARPA: cl...@sun.soe.clarkson.edu
ECE Department UseNet: uunet!sun.soe.clarkson.edu!cline
Clarkson University BitNet: BH0W@CLUTX
Potsdam, NY 13676 AT&T: (315) 268-6591
Jim Adcock
> trivial programs. Does anyone have any information as to whether this is
> true or not?? I found that using advantage C++ also produced large
> executables...one of the reason why I am using Zortech C_++ currently. It does
> not seem to have this problem (executable size seems on average to be about
> 1/5 the size of advantage c++ code).
> We're talking 35K here for a hello world program in advantage...something
> that can't be tolerated on the PC. One source gave the comparable eiffel
> program a number even much higher.
For reference here's some sizes comparing various C and C++ compilers on
my mid-range 680x0 Un*x based system:
linked& compile
executable only
hello world using stdio.h -- ie a 'printf' statement
cc 12920 144
CC 13056 176
gcc 17081 172
g++ 17242 172
hello world using stream.h -- ie cout << "hello world\n"
CC 34232 617
g++ *** 4577
a null program: main(){} -- to test size of run-time environment
cc 4240 83
CC 4372 111
gcc 6622 120
g++ 6783 120
*** I don't have a compiled stream library for g++
cc is hp-ux 6.5 C compiler
CC is AT&T cfront using hp-ux 6.5 as the back end
gcc is gnu-c for the 68020
g++ is gnu-c++ for the 68020
All sizes are file sizes in bytes -- code sizes are obviously somewhat
smaller -- for example cc -O -S null.c generates a _main subroutine of exactly
one machine instruction -- rts [return from subroutine]
Some conclusions:
Trivial C programs are not exactly tiny under un*x no matter what.
No great difference in executable size between C and C++ under un*x.
C and C++ executables for small programs [simple tools] are probably several
times smaller than other OOPL exacutables due to a simpler run time environment.
G++ compiles can be several times bigger than CC compiles since G++ generates
code for in-line functions [while also maybe in-lining them.]
Sure would be nice to have an OS with good support for shared libraries.
Paul E. Black
/* *created "Wed Oct 9 13:16:25 1985" *by "Paul E. Black" */
/* *modified "Mon Oct 19 13:20:35 1987" *by "Paul E. Black" */
/*------------------------------------------------------------------------*/
/*
* This file contains a macro definition for ASSERT. In your code you
* can place statements like:
* ASSERT(0 <= row && pNodePtr->rowSize > 3);
* If your program is compiled with RIGOROUS defined, for example
* cc -DRIGOROUS ..., the assertion is checked. If RIGOROUS is not
* defined, the assertion creates no code. Therefore you can ASSERT
* very complex or time consuming things, e.g. foo should be in a table,
* which you would not want to check during normal operation.
*
* This ASSERT differs from the C standard "assert" in that no exit()
* or abort() occurs: there is only a message to stderr. Also the
* default is that ASSERT does nothing and must be turned on, whereas
* "assert" is on as a default and must be turned off.
*/
/*------------------------------------------------------------------------*/
#ifdef RIGOROUS
#define ASSERT(ex) {if (!(ex)) (void)fprintf(stderr,"ex not true in %s, line %d\n",__FILE__,__LINE__);}
#else
#define ASSERT(ex)
#endif
Paul E. Black | UUCP: ...{pyramid,amdahl,ames}!oliveb!cirrusl!paul
CIRRUS LOGIC, Inc. | Internet: cirrusl!pa...@olivetti.com
1463 Centre Pointe Dr. | Voice: 408-945-8305 extension 210
Milpitas, CA 95035 USA
Patrick Logan
:) In article <2...@pink.ACA.MCC.COM> r...@pink.aca.mcc.com.UUCP (Ron Guilmette) writes:
:) >For me, Eiffel was kind of like a chastity belt. It definitely keeps
:) >you "pure" but you will probably have less fun. :-)
:)
:) It struck me, in fact, that a good many of Dr. Meyer's comparisons between
:) C++ and Eiffel boiled down to "C++ lets the programmer foul things up in
:) any way he pleases, while Eiffel insists on doing it right". This is, in
:) fact, a long-standing philosophical difference between the C camp and the
:) Pascal camp.
Instead of the phrase "doing it right" I think it would be more fair
to paraphrase with "doing it according to some principles of sound
software construction." As I read it, the phrase "doing it right"
carries more self-righteousness than I felt existed in the original
article. The article mentioned or referred to the guiding principles.
:) The Pascal side favors using the language to impose discipline, which makes it
:) a LOT easier to get reliable, well-behaved programs but can make it harder
:) to get the desired results with those programs. Which set of tradeoffs is
:) better depends on the circumstances and the people.
:)
:) (Me? I find the Pascal theory very attractive but at the moment am fully
:) in the C camp for pragmatic reasons. Combining the virtues of the two
:) ought not to be impossible but seems to be difficult in practice. Perhaps
:) a mixed approach is better than trying to pick one or the other.)
:) --
:) You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology
:) but it's not worth it. -Collyer| uunet!attcan!utzoo!henry he...@zoo.toronto.edu
The logic here seems to be the following:
The argument of C++ vs. Eiffel is similar to the typical C vs. Pascal argument.
Therefore Eiffel is in the Pascal "camp".
Therefore Eiffel will have the same problems as Pascal.
I wouldn't consider this sound logic. Its application could lead
someone away from even attempting to evaluate Eiffel.
--
Patrick Logan | ...!{decwrl,sequent,tessi}!mntgfx!plogan
Mentor Graphics Corporation | plo...@pdx.MENTOR.COM
Beaverton, Oregon | "My other computer is a Lisp machine."
Snorri Agnarsson
> 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!
Well -- I agree with that argument. However I agree with you that assertions
are good (at least they are better than nothing), but I think well
formulated preconditions and postconditions, written as documentation, are
necessary and sufficient. Assertions can serve as scaffolding for testing.
>>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?
In my opinion garbage collection is the single most useful feature
of a programming language. Without garbage collection polymorphism
is severely handicapped and programmers tend to shy away from clean
designs because of the restrictions imposed by the lack of garbage
collection. Consider the following C function:
Usage:
x:=plus(y,z);
Precondition:
y and z contain integers represented as zero terminated
character strings of digits.
Postcondition:
x contains the sum of y and z, as a zero terminated
character string of digits.
If C had garbage collection we could write code such as:
x=plus(x,plus(y,z));
...
y=x;
Instead we have to write as follows:
t1=plus(y,z);
t2=x;
x=plus(x,t1);
free(t1);
free(t2); /* assuming that the string pointed to by t2
is not pointed to by any other variable */
...
y=strcpy(x); /* unless you want to risk multiple pointers
to the same string, in which case you
would need to be VERY CAREFUL when freeing
that string */
It is often said that garbage collection is too costly, but I suggest
that in the above example the solution with garbage collection is
probably more efficient, both in programmer effort AND in
the speed of the resulting program. By the way, if garbage collection
is too expensive, how about 'malloc' and 'free'? Do you think those
routines are less expensive? Why do you think so?
We should also consider the effort needed to document memory management
issues for our (reusable) modules. If garbage collection is not available
we get two bad effects:
1) The effort of designing a module for a given problem,
PLUS the effort of documenting all the memory management issues
needed to use the module is too great. Therefore you do not
design or use modules. Or perhaps you use them without
adequate documentation, leaving a can of worms for future maintainers.
2) You put a lot of effort into designing, coding and documenting
modules, including all the memory management issues the user
needs to know about to use the modules, so as not to get memory
leaks or heap smashes.
The design document for the modules become so huge and complicated
that nobody uses the modules (or, perhaps, the modules are used,
but incorrectly).
In my opinion garbage collection is the single most useful feature
of Prolog, LISP, SmallTalk, Eiffel, CLU, etc., etc.
How many would use the above languages if they did not have garbage
collection? In my opinion, very few.
> Ralph Johnson
>>Bertrand Meyer
--
Snorri Agnarsson | Internet: sno...@rhi.hi.is
Taeknigardur, Dunhaga 5 | UUCP: ..!mcvax!hafro!rhi!snorri
IS-107 Reykjavik, ICELAND
Piercarlo Grandi
Here's our version of an "assert" (run-time check) macro.
[ ... ]
#ifdef RIGOROUS
#define ASSERT(ex) {if (!(ex)) (void)fprintf(stderr,"ex not true in %s, line %d\n",__FILE__,__LINE__);}
#else
#define ASSERT(ex)
#endif
This is a bit lame... :-). If you create a class for assertions, with
constructors and destructors, you can have them automatically checked at
block entry and exit; general idea is:
{
ENSURE(entry-condition,exit-condition);
....
}
where ENSURE expands to an immediate check for entry-condition, and wraps up
exit-condition in some destructor of a dummy object. With G++, if you use
wrappers, you can even have some contrived form of class invariants.
In general constructors and destructors in C++ allow you to define almost
fully general entry-exit functions (I posted some months ago two small
classes, for clean exception handling and tracing, that use this aspect of
the language). In practice the only limit is the non easy problem of non
local dynamic control transfers; in theory destructors ought to be called
whenever the current block instance is passivated and constructors whenever
it is activated. (in the general case, not in C++ yet (:->), you can reenter
and leave a block *instance* many times).
Notably, setjmp/longjmp does ignore destructors...
This is a well known problem; BS supposedly is thinking about macaroni and
catch/throw and continuations ... :->
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.abe...@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: p...@cs.aber.ac.uk
Henry Spencer
>Trivial C programs are not exactly tiny under un*x no matter what.
Originally they were. But a lot of vendors (including Berkeley, which is
de facto a vendor) have gotten awfully casual about the sizes of programs
in recent years. Under pdp11 Version 7, small programs really were small.
--
You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology
Bjarne Stroustrup
I stated in an earlier message that I was unwilling to share a stage
with Bertrand Meyer because of his grossly impolite and insulting
behavior toward me, my friends, and professional colleagues.
He replied that my claims are groundless.
Clearly we cannot both be telling the truth. Many people who attended
ECOOP'87, and some who attended OOPSLA '88, are in a position to know
for themselves which of us is lying. Others can read this whole
distasteful series of exchanges starting with Bertrand Meyer's
original posting and make a guess. Bertrand Meyer's company's use of
AT&T's name and quotes from my copyrighted works in its advertising
(without permission, of course) is also available for all to see.
The present exchange is in itself a good example of why I prefer to
have as little as possible to do with Bertrand Meyer. He has too
often failed to attain the minimal standards of common courtesy and
detachment from commercial concerns necessary for a technical exchange.
For example, `part two' of his technical comparison of C++ and Eiffel
contained a litany of unfounded accusations using extreemely loaded
vocabulary: `censorship, money, power, intimidation, hype, one-sided
propaganda, scared indeed, suppressed, pre-settled panels, biased
articles, trying to crush.'
- Bjarne Stroustrup
PS By replying to his postings I did enter into a public discussion with
Bertrand Meyer. That was probably a mistake, but I considered it a very
real danger that unanswered accusations could become accepted `fact.'
Marshall Cline
>From article <7730...@p.cs.uiuc.edu>, by joh...@p.cs.uiuc.edu (Ralph Johnson):
>>>Written 6:48 pm Jun 4, 1989 by bert...@eiffel.com (Bertrand Meyers):
>>>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?
>In my opinion garbage collection is the single most useful feature
>of a programming language.....
>.... Consider the following C function: [...deleted...]
>If C had garbage collection we could write code such as: [...deleted...]
>Instead we have to write as follows: [...deleted...]
I'm going to *TRY* not to take sides in the war over the value of GC.
I **AM** going to say that the line of thinking is getting *OUT*OF*HAND*!!
The original poster (Bertrand Meyers) said he liked GC for such-in-such
a problem. The respondent (Ralph Johnson) said real-time software wasn't
suited for GC. Now we get Snorri Agnarsson saying that he can come up
with an example where GC is useful. WAKE UP FOLKS! GC *IS* a useful
feature *SOMETIMES*. It *MAY* not be a useful feature *ALL* the time!
The argument is getting WAY off course. It's simply not true that:
"Language X is better than Y *ALL* the time because
it has feature Z which is useful *SOME* of the time".
>It is often said that garbage collection is too costly, but I suggest
>that in the above example the solution with garbage collection is
>probably more efficient, both in programmer effort AND in
>the speed of the resulting program. By the way, if garbage collection
>is too expensive, how about 'malloc' and 'free'? Do you think those
>routines are less expensive? Why do you think so?
No one in the C++ camp is saying that malloc()/free() are "free".
The point is simply that malloc()/free() is ***CONTROLLABLE***.
That's what C/C++ programmers like: TO BE IN CONTROL.
That't what Eiffel programmers DON'T like: TO BE FORCED TO CONTROL.
*NO* *NO* *NO* language is best under *ALL* *ALL* *ALL* circumstances.
Any sufficiently experienced computer professional chooses the best tool
to fit the job.
C++ folks don't want to be FORCED to have garbage collection ALL the time.
Eiffel folks don't want to be FORCED to memory allocation ALL the time.
C++ folks like the machine to do exactly what/when they tell it to.
Eiffel folks like a higher level of abstraction from the machine.
Conclusion: Let's drop the garbage collection argument from this discussion.
>>>Bertrand Meyer
>> Ralph Johnson
>Snorri Agnarsson
Marshall Cline
--
________________________________________________________________
Dr. Marshall P. Cline ARPA: cl...@sun.soe.clarkson.edu
Bjarne Stroustrup
We seem to have improved a bit. 2.0 gives:
$ cat h.c
#include <stdio.h>
main()
{
printf("Hello, world\n");
}
$ nCC h.c
nCC h.c:
cc h.i /usr/lib/nlibC.a
size a.out
$ text data bss dec hex
18432 2048 0 20480 5000
$
on my VAX
The printf() version equals C as usual.
Larry Campbell
-
-C++ folks don't want to be FORCED to have garbage collection ALL the time.
-Eiffel folks don't want to be FORCED to memory allocation ALL the time.
The problem is, neither gets the choice. In C++, you CANNOT have garbage
collection. In Eiffel you cannot PREVENT garbage collection. Why not
give the programmer a choice?
Contrast this with Modula-3, which provides GC, but makes it optional.
--
Larry Campbell The Boston Software Works, Inc.
camp...@bsw.com 120 Fulton Street
wjh12!redsox!campbell Boston, MA 02146
Jean-Marc Nerson
>No one in the C++ camp is saying that malloc()/free() are "free".
>The point is simply that malloc()/free() is ***CONTROLLABLE***.
>That's what C/C++ programmers like: TO BE IN CONTROL.
>That't what Eiffel programmers DON'T like: TO BE FORCED TO CONTROL.
> ..........
>C++ folks don't want to be FORCED to have garbage collection ALL the time.
>Eiffel folks don't want to be FORCED to memory allocation ALL the time.
In Eiffel:
1) Object allocation is always under programmer's control
since you know when you create a reference to an object.
At execution time, the statement:
obj.Create [Create could have possible arguments]
does 1 or 2 things:
o Call memory allocation routines of the run-time
system. [where sbrk() is used instead of malloc()].
o Possibly execute the body of the Create procedure of the
class obj is a instance of if it has been re-programmed
with some initialization statements.
The only case when memory allocation is not under programmer's
control is for the creation of the first object of the system,
instance of the root (or main) class. One could imagine an
application consisting of only one single class with no object
creation at all except for the root object.
This is not an O-O programming style ...
2) Garbage collection can be under programmer's control.
o Garbage collection is a compilation option.
o If the system is compiled and linked with the garbage collector,
the default mechanism is quasi parallel and self adaptive.
There is also a way for the application to control it by inheriting
from a library class called MEMORY that provides operations
to turn it on and off or even to do a 'Lisp-like' full collection
if wanted.
------------------------------------------------------
Jean-Marc Nerson -- Interactive Software Engineering
ma...@eiffel.com
Michael Pilling [Real people drink purple milk]
> > can talk about the very idea of reusable software components without
> > assertions...
> > maintained by the amplifier). Yet of widely available programming
> > languages, only Eiffel has these notions.
> Assertion checkers, of course, have been used for years as tools outside
> the scope of the language, as libraries, or extracted by tools from
> code comments. Placing assertions within classes as part of the language
> is, I must agree, a very powerful feature. But Eiffel's design philosophy
> calls on programmers to define their classes with assertions in addition
> to coding their implementation; something most programmers aren't used to
> doing and may view as an onerous task. Since assertion checking isn't any
> better than the assertions dreamed up by the programmer, I'm skeptical of
> using it to "replace" unit testing.
I have been encouraging my group software project students to use assertions,
and have found that they take some time to get into the swing of writing
effective and prudent assertions. This feeling is based on their reactions,
I have yet to mark their code (uggggh). Like anything there is a learning
curve and a few people will never really get the hang of it. This is not
to say assertions are a bad feature, it mearly reveals those who should
should be programming and those whose talents lie in other areas. (Perhaps
they could help me with my spelling :-) )
I have been using assertions for 3 years and felt obliged to point out
that they are not intended to "replace" unit testing but to simplify and
augment it. I have found assertions to have the following benifits in
whatever language you choose to implement them.
1. Carefully chosen assertions clarify your understanding of the code
you are writing or reading and force you to reason about what you
are really doing and it's consequences. I have found this to be
the most important benifit. It allows you to produce clearer, simpler
and more efficient CORRECT code.
2. Error detection is increased. You can't fix them if you don't find
them. In a large library module, certain code may never be executed
until it fails. This may be 2 or 5 years down the track. Or the error
may not manifest 99% of the time because one errornous result in a
record/structure is only occasionally accessed. Assertions add another
layer of testing - those of self consistency and plausability
e.g.s
While traversing a doubly linked list you can assert that the
current link points back to where you came from.
A positive square root should be smaller than the input and
when squared should give the input.
3. Errors are detected close to their occurence in space and time.
Symptoms of the error may be much further away when the real causes
have been obscured. This makes fixing the bug easier because you don't
have to waste so much time looking for it.
e.g.
Space - Assertions fail in your binary search routine - jumping
to the bottom half of the array actually gave you a
smaller key!! Conclusion: The caller lied when they claimed
the array was sorted. Saved from wasting time trying to
debug the correct binary search routine.
Time - Stange errors are occurring in your program. You suspect
the memory arena's been trashed but have no idea who did it
and when. Assertions can often detect the culprit soon after
they commit the crime.
4. When you think you've fixed the bug the saftey net is still there to
tell you you were wrong. In libraries this to can be useful to detect
bugs in infrequently used code rather than letting them slip through
unnoticed.
5. They can make programs more robust and protect data
by stopping their progress in emergancy situations.
Real Life example:
Data General AOS/VS operating system utility "Exec" hung itself
after uttering: Internal inconsistancy error -
negative time encountered.
In reality, one of the sysops had corrected the time of day
because it was fast. Exec caught itself completing a task before
it started and thought the clock hardware had failed.
It correctly aborted system processing rather than risk damaging
timestamps used for backups and other data consistancy functions.
6. You can avoid buggarising your code with error handlers. Why should you
attempt to clean up other peoples mistakes. Your code is simpler and
more likely to be correct.
eg
When I did the group software project I was the only one to
use assertions. During intergration, people would run to me
saying YOUR module had ANOTHER assertion failure. More often
than not, I had the pleasure of replying "Oh, that means your
not sorting that array you passed me like you were supposed to."
I have personally found the use of assertions to save me 80% of my previous
debugging time and effort. They allow you to tackle problems that would be
almost insumountable otherwise, particularly when useing malloc & free.
Like any good investment they pay many returns over a long period.
Assertions should be included in the language (definition and compiler proper)
so you can turn them off (at your own risk). Preprocessed assertions often
produce much more code per assertion and can not check that your assertions
do not have side effects. (Side effects prevent you from turning them off
because you program behaves differently.)
Michael Pilling,
Computer Science Department,
University of Queensland,
St Lucia, 4067 Australia.
Erland Sommarskog
>The problem is, neither gets the choice. In C++, you CANNOT have garbage
>collection. In Eiffel you cannot PREVENT garbage collection. Why not
>give the programmer a choice?
I don't have my OOSC around at the moment, but far as I recall Eiffel
does give you a choice. You can turn off garbage collection if you
absolutely have to. And calls corresponding to manually free memory
are also available. But you are certainly not encouraged to use them.
My apologies if I'm wrong on this point.
I don't speak C++, but an object-oriented langauge without garbage
collection seem quite useless to me. Or rather: it's not really
an object-oriented langauge, just a more structured form of C.
--
Erland Sommarskog - ENEA Data, Stockholm - som...@enea.se
Bowlers on strike!
Robert Marti
> In C++, you CANNOT have garbage collection.
Wrong. You can redefine operator new to use a garbage collecting
allocator, for example the one written by Hans-Juergen Boehm and Alan
Demers, which is described in
H.-J. Boehm, M. Weiser: Garbage Collection in an Uncooperative
Environment. Software Practice & Experience, Sept. 1988,
pp.807-820.
and available from the archive server at RICE University.
In release 2.0, you can even redefine operator new on a class per class
basis.
--
Robert Marti Phone: +41 1 256 52 36
Institut fur Informationssysteme
ETH-Zentrum CSNET/ARPA: marti%inf.e...@relay.cs.net
CH-8092 Zurich, Switzerland UUCP: ...uunet!mcvax!ethz!marti
Mark Lawrence
}
} > I would like to start a discussion of Eiffel vs. C++.
And then bert...@eiffel.UUCP (Bertrand Meyer) wrote:
[...AmongOtherThings...]
} Money, power and intimidation cannot buy everything. Once the lights
} are out, the hype is gone, the pre-settled panels have been held and
} the biased articles have been read, sooner or later people will go
} home and start to work. Then they will judge on costs and benefits,
} not promises and politics.
I remember going to the vendors exhibit during the '87 Summer Usenix in
Phoesnix (the occasion of the infamous Jobs line: "X is braindamaged and
will fail...". hah.). I recall sitting down with Mr. Meyer at the time
for a walkthrough of Eiffel (Cepage?) and trying to understand just what
it _was_. I was impressed at the time with the possibilities of the
environment (and still am, based on all that I've heard about it). But
I'll never give it (nor Objective C) serious consideration for use in my
company.
For me, it boils down to the same reasons why I refuse to buy a Gould
machine running MPX, a DEC machine running VMS or a DG machine running
AOS. It's the same reason why I think it unreasonable to develop the UI
portions of our applications in native SunViews. It's the same reason
why I think it unwise to commit to a database interface that has no SQL
capability.
I want a choice.
I am extremely uncomfortable with the prospect of a vendor who has me
locked into their proprietary product telling me what is and isn't
important in terms of bug fixes and new product features -- I'd like to
be able to make that choice in a free market. Quite simply, Objective C
and Eiffel don't give me that choice and C++ does. The former may be
more elegant in design and execution and have some arguably better
features and capabilities, but I'll only seriously consider the latter,
warts (from its procedural heritage) and all. I suppose that if I
could reshape the world to my own liking, I would choose software tools,
implementation languages and pieces of systems on technical merit alone.
But the world isn't like that and so I don't. What's more, it has
nothing to do (from my perspective) with the power, money and
what-have-you behind "The Telephone Company" (anybody for "The President's
Analyst"?). Such inuendo seems to me to be a bit far-fetched.
Jim Adcock
> -Eiffel folks don't want to be FORCED to memory allocation ALL the time.
>
> The problem is, neither gets the choice. In C++, you CANNOT have garbage
> collection. In Eiffel you cannot PREVENT garbage collection. Why not
> give the programmer a choice?
>
Correct me if I'm wrong, but I can't think of anything in C++ that
prohibits GC. It's just that no GC comes standard with C++. But then,
not much in the way of libraries comes with C++. Certainly, there are
a number of GC techniques that could be applicable to C++ -- its just hard
to find a GC technique that would be close to universally applicable.
Perhaps a harder [impossible?] problem is to create a GC that is easily
portable to the wide variety of machines that C++ supports. More modern
GCs tend to get involved with the virtual memory hardware in order to speed
the scan for garbage. Clearly these kinds of approaches are hard to port
between machines.
Also, GC tends to greatly limit how "real time" an application can be.
So classes written using GC tend to be unusable in more demanding "real time"
applications. So classes then get divided into two camps. Those using GC
and those not using GC.
Still, it would seem to be useful to have some kind of GC available for C++,
if only to report on objects that programmers have lost track of.
John Cowan
Pfui. Note the Reiserism. Correct ANSI C would use #ex outside the quotes,
rather than ex inside them. Does C++ make Reiserism standard? I hope not.
--
John Cowan <co...@marob.masa.com> or <co...@magpie.masa.com>
UUCP mailers: ...!uunet!hombre!{marob,magpie}!cowan
Fidonet (last resort): 1:107/711
Aiya elenion ancalima!
Daniel Elbaum
programming language than Pascal. You all agree, don't you?
--
The workaday world must remain transparent to those who maintain it if
they are to find inspired within them a vision of the history they create.
({uunet,tektronix,reed,sun!nosun,osu-cis,psu-cs}!oresoft!(dan)@oresoft.uu.net)
Dave Berry
> C++ has a notion of friend function which, as I understand it, makes
>it possible to define routines outside of the object-oriented framework.
>There is nothing equivalent in Eiffel. This facility is not missed.
In C++ a class A may define other classes to be its friends; these classes
can access all attributes and members of A. From the book (OOSC), Eiffel
does seem to have an equivalent, namely the facility where members may be
exported to certain named classes only. Both mechanisms allow A to control
access to part of itself. The Eiffel mechanism gives finer control.
I don't know if this finer control will matter in practice.
Friend functions in C++ are similar, but allow the integration of object
oriented software with non-OO software, in keeping with the rest of the
language.
>Compatibility with C means that in C++ you still have pointers, type casts,
>pointer arithmetic, function pointers, malloc, free. I strongly disagree
>with this approach if the goal is to obtain software quality. In Eiffel,
>the choice has been made. None of these low-level features are present;
>needless to say, they are not missed.
Except by all the people asking for them on USENET ( semi :-) ).
I would say that languages don't encourage software quality if they require
the use of low-level features unnecessarily. C & C++ undoubtably do so,
although C++ will improve when type parameterisation and multiple inheritance
are available. This doesn't mean that such features should not be provided.
Sometimes some people need low-level control. What is important is that they
should be able to hide their use of such features from the rest of the program.
I find it odd that Meyer considers function pointers "low-level". There was
some discussion of function parameters in Eiffel a couple of months ago, and
they seemed to offer neater solutions (IMAO) to some problems than the
alternative techniques. Treating functions as first order objects (or
"nearly firat order" objects) is usually considered high level.
Dave Berry, Laboratory for Foundations db%lfcs.e...@nsfnet-relay.ac.uk
of Computer Science, Edinburgh Uni. <Atlantic Ocean>!mcvax!ukc!lfcs!db
Britain without the Queen is like a democracy without a monarch.
Scott Simpson
=object-oriented programming), a well-known and respected
=Professor from a university on the East Coast invited me
=to participate in a panel at the next conference
=(New Orleans, early October 1989). The idea for the panel was
=to discuss the designs of major object-oriented languages, with
=the Eiffel, Smalltalk, C++ and Objective-C viewpoints presented
=respectively by myself, Dr. Adele Goldberg from ParcPlace, Dr. Bjarne
=Stroustrup from AT&T and Dr. Brad Cox from Stepstone. This looked liked a
=great idea and I agreed immediately.
=
= Some time later I was told that I was out of the panel. The reason:
=Dr. Stroustrup had declared that he would not participate if I did.
=Perhaps even more stunning than Dr. Stroustrup's reaction was the panel
=organizer's apparent inference that, if A refuses to be on a panel with B
=(who himself welcomes the opportunity), then B should be excluded.
=Then as now I did not understand why the inference is not that A must be
=taken to his word.
In article <94...@alice.UUCP> b...@alice.UUCP (Bjarne Stroustrup) writes:
=Bertrand Meyer, president of Interactive Software Engineering, the
=supplier of Eiffel, is correct on one point: I did refuse to appear on
=a panel with him. My reasons are personal. He has insulted my friends
This is censorship and this sucks. I would have kicked you off the panel.
Am I the only one who finds this behavior reprehensible? The panel chair
who withdrew his offer to Dr. Meyer gets an F for bad judgement too.
Scott Simpson
TRW Space and Defense Sector
oberon!trwarcadia!simpson (UUCP)
trwarcadia!sim...@usc.edu (Internet)
LTH network news server
I do not like the current ``discussion'' between Bertrand Meyer and
Bjarne Stroustrup. I think it was wrong to start it, and I think it
is inappropriate for this news group.
In particular, I think other people should refrain from commenting as
no unbiased account for the actual circumstances is available.
It is my hope that Bertrand Meyer and Bjarne Stroustrup will be able to
bury the axe sometime in the future, so that they can benefit from
each other's contributions to programming language design. So will
the rest of us.
Dag Bruck
--
Department of Automatic Control Internet: d...@control.lth.se
Lund Institute of Technology
P. O. Box 118 Phone: +46 46-108779
S-221 00 Lund, SWEDEN Fax: +46 46-138118
Bjarne Stroustrup
I hear that some people have gotten the impression that the proposed
language designers' panel Bertrand Meyer was referring to was actually
going to take place at OOPSLA'89 (with C++ represented and Eiffel not).
This is not the case. As far as I know, the panel wasn't even proposed
to OOPSLA. I have heard absolutely nothing about that panel since last
October when I declined to be on it.
I am not involved in the OOPSLA'89 planning process.
Snorri Agnarsson
From article <CLINE.89J...@sun.soe.clarkson.edu>, by cl...@sun.soe.clarkson.edu (Marshall Cline):
> No one in the C++ camp is saying that malloc()/free() are "free".
> The point is simply that malloc()/free() is ***CONTROLLABLE***.
You seem to be suggesting that malloc()/free() is more controllable than
malloc()/garbage collection. If so, then in what sense??
Garbage collection can be time-consuming, of course, but so can free().
If you have a language with garbage collection, it is usually very easy
to ensure that no garbage collection gets performed in some critical
section by simply not allocating any memory.
> That's what C/C++ programmers like: TO BE IN CONTROL.
> That't what Eiffel programmers DON'T like: TO BE FORCED TO CONTROL.
I do not understand what you are trying to say.
> C++ folks don't want to be FORCED to have garbage collection ALL the time.
That's good since in most instances they don't have garbage collection any of
the time.
But maybe some of them would like to have garbage collection some of the time.
> Eiffel folks don't want to be FORCED to memory allocation ALL the time.
????????????
> Conclusion: Let's drop the garbage collection argument from this discussion.
If you think talking about garbage collection is a waste of bandwidth you
are certainly entitled to that opinion, but I do not have to agree with you.
> Marshall Cline
Alastair Dallas
> From article <7730...@p.cs.uiuc.edu>, by joh...@p.cs.uiuc.edu:
> >
> > Since there are so many C programmers, this means that C++ has a tremendous
> > marketing advantage.
> ^^^^^^^^^
>
> Although It may sound anachronistic and/or idealistic, I believe that
> programming languages should be chosen based on criteria such as security
> (in its wider sense), reliability, extensibility, readability etc. rather
> than by its marketing advantage or upwards compatibility with widespread
> traditions.
Yes, it does sound idealistic. Some will make the language choice without
considering what everyone else is doing, but most will not. Speaking from
my experience with the dBASE language throughout the '80s, the ability to
ask questions, buy books, attend seminars, etc. when you are using a language
definitely factors in. It's not working out exactly the way I thought it
would after reading Ted Nelson or Alvin Toffler... Sure, the number of
choices is greater, we have narrowcasting replacing broadcasting, but
people of similar needs and interests still clump together. If you have
three all-ballet channels on cable tv and you're a ballet nut, you're
going to coordinate which one you watch with other ballet nuts so you can
talk about it the next day. But I digress (massively)...
Good luck to Eiffel, to Pal (the programming language inside Paradox), to
Fred (the programming language inside Framework). This is a regenerative
process; they each may be successful one day. Today, if I had to bet the
mortgage money, I'd go with the numbers and bet on C++.
/alastair/
Disclaimer: These are my opinions. Ashton-Tate doesn't speak for me, and
I return the favor.
Geoffrey Jones
> As a small issue in C++'s favour, each C++ class
> can contain a destructor routine which is executed whenever an object
> of that class is destroyed, which will be whenever the object goes out
> of scope (e.g., at program termination) or whenever it is actively
> deallocated from the dynamic memory pool. No such operation exists in
> Eiffel. This makes certain types of programming awkward in the latter.
Oh dear, searching through my comp.lang.eiffel archive I grepped on
"destructor" and found to my surprise that Jos Warmer (j...@cs.vu.nl)
had already raised this point in article <21...@vlot.cs.vu.nl>. I'll
include a little of it here because the article has probably expired
from most sites by now and many comp.lang.c++ people following this
discussion won't have read it before:
> Some problems with garbage collection:
>
> 1. In the library class FILE one can create a FILE object, open it and use it.
> If the FILE object is not referenced anymore, the memory used by it
> will be reclaimed by the garbage collector.
> However, each file that is opened should be closed before the FILE object
> is destroyed.
>
> This can not be forced by the FILE class, but it is left to the client.
> It should be much safer if the FILE class could ensure that each file
> is closed before the object pointing to it is destroyed.
>
[ ... much more removed ... ]
>
> A possible solution:
>
> In C++ so-called destructors can be defined. A destructor is a routine
> that is called on an object when the object is being freed.
> A destructor contains code that performs some cleanup before the object
> is destroyed.
>
> These destructors can be used to solve the problems described above.
> I cannot find a way to solve these problems in eiffel. Should such
> a feature be added eiffel, or are there other solutions.
In article <1...@eiffel.UUCP> Bertrand Meyer (bert...@eiffel.UUCP)
follows up to provide a (patch) solution:
> In version 2.2 the library class MEMORY will include an argumentless
> procedure called dispose, to be invoked by the garbage collector (if
> active) when an object is freed. The original version of this class
> has an empty body and hence does nothing. Any class can inherit
> from MEMORY and redefine this procedure to do something, for instance
> close a file as in Mr. Warmer's example.
>
> Two caveats:
>
> - The exact details are still subject to change.
>
> - The next version (Eiffel 3, end of 1989) will support the
> possibility of treating all objects as persistent (the set of all
> objects of an Eiffel session becoming a database). In this context
> the problem addressed by Mr. Warmer becomes part of a larger
> requirement (describing what should be done to any object when
> the session terminates, or when it is stored to a file by an automatic
> mechanism). This means that the 2.2 solution may be overridden at that
> time by a more general scheme.
The version 2.2 solution is indeed a step in the right direction but I
don't see that it should be the final answer. An "obvious" solution
might be to imbue Eiffel's `Forget' with an enlarged semantics, thus
moving the solution under the auspices of the language definition and
away from all the ad hoccery involving strange class inheritences. I
would propose that programmers could define their own `Forget'
routines analogously to programmer-defined `Create's. Thus the
responsibility to call server class terminating routines (e.g.,
`close' in class FILE) would be removed from the server's clients (as
Dr Meyer's v2.2 solution seems to allow), as well as from the vagaries
of the garbage collector which may or may not be active depending on
all sorts of contingencies not the least of which is whether the GC was
enabled at compile-time(!). I believe it would be proper if each class
instance had its programmer-defined Forget routine called whenever
that instance went out of scope of all other system objects, i.e., if
a successful garbage sweep of the object could be made or whenever the
program was terminating.
Naturally these are only tentative thoughts which should be weighed in
the light of added language complexity and so forth. However the
problem of proper object termination is a real one that must be
addressed in the not-too-distant future if Eiffel is to become a
suitable platform for many types of computing tasks.
Geof.
----------------------------------------------------------------------------
Geoffrey Jones ACSnet: ge...@nswitgould.oz.AU
Dept. of Computer Science ARPA: geof%nswitgou...@uunet.UU.NET
U. of Technology, Sydney UUCP: ...!munnari!nswitgould.oz.AU!geof
P.O. Box 123, Or try: munnari!nswitgould.oz.AU!ge...@uunet.UU.NET
Broadway, 2007
AUSTRALIA Phone: (02) 218 9505
----------------------------------------------------------------------------
Alastair Dallas
>
> I do not like the current ``discussion'' between Bertrand Meyer and
>
> Dag Bruck
I disagree. Yes, no one else on the net has anything but opinion to add to
the discussion and the debate is more personal than factual. By some limited
definition, the thread does not belong here because it is not suitable for a
textbook. But why should we choose to define usenet that way? Primarily,
because the channels would otherwise be clogged by unimportant chatter. I say
we must encourage important people to use this network, even for less than
important things--and I'm not convinced that this debate is unimportant.
_Any_ discussion between Bjarne Stroustrup and Betrand Meyer, no matter how
trivial, is interesting to me. If Wirth and Ritchie started calling each
other names, I'd tune it to that, too. Further, isn't the process by which
a new language achieves acceptance fascinating? You rarely meet technical
people who say they enjoy either sales or politics, and yet those two
activities have a huge influence on science and engineering.
What if we had a record of the things that Edison, Westinghouse and Tesla
said to each other? Are arguments only important in historical hindsight?
m...@cs.rit.edu
>AT&T's name and quotes from my copyrighted works in its advertising
>(without permission, of course) is also available for all to see.
I don't want to get bogged down in the name calling and other
vituperative rantings and ravings that have been going on in these
newsgroups, but this sentence intimates that ISE and Dr. Meyer have
done something improper with Dr. Stroustrup's work and AT&T's name. I
assume Dr. Stroustrup refers to ads such as the one in the July 1988
issue of IEEE Software (inside the front cover). If so, then two
points must be made:
1. Three of the four quotes refer to an article by Dr. Stroustrup in IEEE
Software, and, as a member of the editorial board, I know that the copyright
belongs to the IEEE (this is standard policy).
2. All of the quotes are short, and properly cited in the ad. As such, they
are covered by the fair use doctrine, and ISE has done nothing improper
in using them. I'll leave it to others to determine whether or not the
quotations were used out of context.
3. The only reference to AT&T is in a footnote attached to a table comparing
C++ to Eiffel, and simply is used to document the version of the C++ compiler
used in the comparisons. Rather than slandering AT&T, this provides a
service to readers of the ad.
In short, there seems to be little basis for this particular complaint.
Mike Lutz Rochester Institute of Technology, Rochester NY
UUCP: {rutgers,cornell}!rochester!ritcv!mjl
CSNET: mjl%r...@relay.cs.net
INTERNET: m...@cs.rit.edu
Jim Adcock
> =supplier of Eiffel, is correct on one point: I did refuse to appear on
> =a panel with him. My reasons are personal. He has insulted my friends
>
> This is censorship and this sucks. I would have kicked you off the panel.
> Am I the only one who finds this behavior reprehensible? The panel chair
> who withdrew his offer to Dr. Meyer gets an F for bad judgement too.
All this ill-will and name calling sucks. *I* certainly wouldn't want to
be on a panel if I was afraid it was going to degrade into a pissing match.
Let's leave that to the experts -- Congress.
Brent McPherson
>> -Eiffel folks don't want to be FORCED to memory allocation ALL the time.
>>
>> The problem is, neither gets the choice. In C++, you CANNOT have garbage
>> collection. In Eiffel you cannot PREVENT garbage collection. Why not
>> give the programmer a choice?
Wrong, Eiffel allows the user to turn GC on/off.
>
>Perhaps a harder [impossible?] problem is to create a GC that is easily
>portable to the wide variety of machines that C++ supports. More modern
>GCs tend to get involved with the virtual memory hardware in order to speed
>the scan for garbage. Clearly these kinds of approaches are hard to port
>between machines.
>
It seems to me that GC in a language such as Eiffel is alot easier to
implement since there is no notion of a global variable. The program
starts at the root class and all active objects are objects that can
be reached from the root class. This is a simple tree structure (and
hence easier to traverse).
>
>Still, it would seem to be useful to have some kind of GC available for C++,
>if only to report on objects that programmers have lost track of.
Most people seem to have a rather narrow view of what garbage collection
should be used for. It is not to free objects that programmers
"lose track of". In the hands of a competant programmer GC is a powerful
tool. Data structures can become more compact since different objects
may safely point to the same data. In C (and other languages with
no garbage collection) there is usually one reference per structure.
If the same data is needed in another structure then a new copy is made.
This allows memory to be released easily but is wasteful and slow.
One way in which I have used GC is to keep a fixed-size list of object
references (stored in Least Recently Used order). Objects is this list
could share common sub-structures with other objects in the system.
When the list became full, the Least Recently Used object would drop off
(be removed) from the list. If the object or its components are no longer
referenced by other active objects in the system, they then become
candidates for GC. This is a very easy way to keep a history list of
objects to avoid unecessary computation/disk access for frequently
used objects.
A program designed in this fashion will often outperform a
similar and more complicated C program (since it is a *smarter* program).
Conclusion:
Both GC and explicit free are useful. Structures
that are created/destroyed in a systematic manner are good candidates
for the latter scheme since the programmer knows when an object is
no longer referenced and may be freed. In complicated cases programmers
tend to make mistakes (ei. free used memory or create dangling references).
In these cases GC is the better choice. A wise programmer will use
all tools at their disposal to obtain the best solution to a given problem.
--
Brent McPherson bamcp...@rose.waterloo.edu
David Taylor
> In article <1989Jun13....@LTH.Se>, news...@LTH.Se (LTH network news server) writes:
> >
> > I do not like the current ``discussion'' between Bertrand Meyer and
> > Bjarne Stroustrup. I think it was wrong to start it, and I think...
>
> the discussion and the debate is more personal than factual. By some limited
I like this.
An argument over whether to have arguments.
Are we plagiarizing Monty Python sketches here?
Lorenzo De Leon
>
> I do not like the current ``discussion'' between Bertrand Meyer and
> Bjarne Stroustrup. I think it was wrong to start it, and I think it
refrain from personal "discussions".
Lorenzo De Leon
Odesta Corp.
Northbrook, Ill.
Rene' Seindal
L
e
m
o
n
C
u
r
r
y
!
Tim McDaniel
=Bertrand Meyer, president of Interactive Software Engineering, the
=supplier of Eiffel, is correct on one point: I did refuse to appear on
=a panel with him. My reasons are personal. He has insulted my friends
In article <50...@wiley.UUCP> sim...@poseidon.UUCP (Scott Simpson) writes:
>This is censorship and this sucks.
What nonsense! Too often, people think "censorship" means "the
organizers/owners didn't let me give my point of view". Censorship
involves a GOVERNMENT official who has the power to PENALIZE speech
(etc.). The capitalized words are the important ones.
Within extremely broad limits (such as slander, libel, national
security), if I own a newspaper, or own a radio station, or set up a
conference or party or discussion or debate, I can bloody well do
whatever I want! If I set up a debate on, say, evolution, I don't
have to invite creationists or evolutionists if I don't want to, or
invite any particular person or set of people, because it's MY debate
and I have control. "Freedom of the press belongs to the one who owns
the press."
Bjarne Stroustrup had a complete right to ask any conditions he wanted
for appearance, from unconditional acceptance to unconditional
refusal. Similarly for Bertrand Meyer. But it's OOPSLA's show, and
they have the final right to say who will speak and how. Any
negotiations are between the three of them. If a government official
had intervened (say, idiotic fright about foreign nationals learning
the secrets of object-oriented programming), THEN it would be
censorship.
>I would have kicked you [Stroustrup] off the panel.
Perhaps. If I, the producer of a TV talk show, can have A or B but
not both, I have to judge for myself which one I want. In the OOPSLA
case, I'd want to find out: (a) if it is manifest that one of the two
would contribute far more to the panel, (b) what kind of public
insults, falsehoods, and out-of-context quotations Meyer has actually
delivered or is likely to deliver.
*IF* Stroustrup has demonstrated in previous conferences an effort to
have technical discussions while Meyer has indulged in grossly
unprofessional insults and misrepresentations, it would certainly tell
very heavily against Meyer. *IF* these allegations are clearly true
AND as serious as Stroustrup says, THEN it would be unfair to have
Meyer on the panel. *IF* these allegations are clearly false or
frivolous, it would be just as unfair to have Stroustrup on the panel.
But I don't have any information to decide this case, and I suspect
Scott Simpson doesn't either. If OOPSLA didn't have the information
either, their behaviour was unjust.
>Am I the only one who finds this behavior reprehensible?
I certainly hope so!
--
"Let me control a planet's oxygen supply, and I don't care who makes
the laws." - GREAT CTHUHLU'S STARRY WISDOM BAND (via Roger Leroux)
__
\ Tim, the Bizarre and Oddly-Dressed Enchanter
\ mcda...@uicsrd.csrd.uiuc.edu
/\ mcdaniel%uicsrd@{uxc.cso.uiuc.edu,uiuc.csnet}
_/ \_ {uunet,convex,pur-ee}!uiucuxc!uicsrd!mcdaniel
Larry Campbell
that "C++ prevents GC and Eiffel mandates it", people jumped all over that
statement, insisting that you can graft GC onto C++ and you can turn GC off
in Eiffel.
What I should have said is that "there is no language support for GC in C++"
(true) even though by suitable hackery you can graft it in; I've even seen
GC grafted onto plain old C. In my opinion, this doesn't count; since
there's no language support, if you expect to use it, you're nonportable.
(I haven't seen the C++ GC wart, but the C one required assembly language
and an intimate knowledge of stack frames and register contents.)
And while Eiffel apparently lets you temporarily disable and enable GC on
a global basis, this is not a very fine grain of control.
Modula-3, by contrast, allows you to decide on a type-by-type basis whether
objects of the type are to be GC'd or not. This seems to me to be the best
solution.
Norman Diamond
>>>Bertrand Meyer, president of Interactive Software Engineering, the
>>>supplier of Eiffel, is correct on one point: I did refuse to appear on
>>>a panel with him. My reasons are personal. He has insulted my friends
In article <50...@wiley.UUCP> sim...@poseidon.UUCP (Scott Simpson) writes:
>>This is censorship and this sucks.
>>I would have kicked you [Stroustrup] off the panel.
In article <12...@garcon.cso.uiuc.edu> mcda...@uicsrd.csrd.uiuc.edu (Tim McDaniel) writes:
>What nonsense! Too often, people think "censorship" means "the
>organizers/owners didn't let me give my point of view". Censorship
>involves a GOVERNMENT official who has the power to PENALIZE speech
>(etc.). The capitalized words are the important ones.
>it's OOPSLA's show, and they have the final right to say who will speak and how.
Time to poll the dictionaries on the precise meaning of "censorship" eh?
Maybe we need an approximate synonym to describe what is happening. We
aren't arguing semantics here because we all agree on what happened; but
we're arguing the syntax of how to designate it. Anyway...
Surely there are more people besides Bjarne Stroustrup who, having been
offended by Bertrand Meyer's personality, would opt to kick themselves
off a panel. They should be permitted to kick themselves off a panel.
No one else should do the kicking. No one should have kicked Bertrand
Meyer off the panel either. A professional, non-profit (tax assisted,
indirectly), educationally oriented institution proposed a technical
discussion for the edification of all. The proposed panelists all have
some technical contributions and could (potentially) participate without
degenerating into egotism or mudslinging. OOPSLA should not have kicked
anyone off the panel *a priori*. When a participant exceeds the bounds
of fair technical debate, it would be appropriate to remove him or her
at that time. Each participant can decide whether, in order to avoid
such embarrassment, to perhaps not participate.
There are many reasons why possible participants might choose to exclude
themselves. Unfortunately OOPSLA has chosen to take sides, display
prejudice, and tar itself.
--
Norman Diamond, Sony Computer Science Lab (diamond%csl.s...@relay.cs.net)
The above opinions are claimed by your machine's init process (pid 1), after
being disowned and orphaned. However, if you see this at Waterloo, Stanford,
or Anterior, then their administrators must have approved of these opinions.
Jeff Dalton
>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
Jeff Dalton
>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.
I think this may be a more complex issue than it at first appears.
Richard O'Keefe has argued on several occasions that string processing
is more efficient when there isn't a built-in string type. I'm not
sure he's correct, but he generally knows what he's talking about.
(I'm sorry I don't have any "real" references -- there were just
some articles in Comp.lang.c (I think) and Comp.lang.prolog.)
Jim Adcock
> (true) even though by suitable hackery you can graft it in;
(false.) Overloading "new" and "delete" constitute C++ support for GC in
my opinion, since I can now attach the GC scheme of my choice where I want
it when I want it. Either as a global decision, or on a class by class basis.
> I've even seen
> GC grafted onto plain old C. In my opinion, this doesn't count; since
> there's no language support, if you expect to use it, you're nonportable.
(false.) Since Boehm's GC is designed to be portable, and has been ported to
many different machine, there is at least one "public domain" GC that you
can take with you when you move to a new machine. Ideally, write portable
C++ code using G++ or cfront and Boehm's GC, and you should be able to port
transparently to just about any machine you choose.
> (I haven't seen the C++ GC wart, but the C one required assembly language
> and an intimate knowledge of stack frames and register contents.)
Warts are in the eye's of the beholder. In my opinion, forcing users of a
language to use one particular GC scheme, where no particular GC scheme is
universally applicable, is a wart, since this destroys a language for many
of its would-be users. C++ attempts to leave as many of these decisions as
possible in the hands of its users. Thus I am not force to use one person's
idea of what I/O should look like. Nor am I forced to use one person's GC
scheme.
Bjarne Stroustrup
There is an important question that needs to be asked in regards to GC
of C++ programs:
``When an object is garbage collected should its destructor
(if any) be called?''
People often simply assume that the answer is `yes.'
This is not obvious. Consider GC as simply a relatively cheap way of
achieving an infinite memory. If we had a genuine infinite memory and
used `new' and `delete' the constructors for objects allocated using
`new' and not deleted would not be called (as C++ is currently defined).
In other words, it would still be the programmer's task to call `delete'
to trigger the destructor even if memory usage was of no concern.
There is therefore two possible models for garbage collection of C++:
(1) the `infinite memory' model where destructors are only called
for explicitly deleted objects, and
(2) the `automatic destruction' model where destructors are called
where the memory used to store objects are recycled.
The former is more `manual' and more predictable in terms of when things
happen. The latter more automatic and (I think) imposes the rule that every
object on the free store must be destroyed on normal program termination.
I suspect that the programming of destructors will differ significantly
dependent on the model adopted.
Jonathan Shopiro
> There are therefore two possible models for garbage collection of C++:
>
> (1) the `infinite memory' model where destructors are only called
> for explicitly deleted objects, and
> (2) the `automatic destruction' model where destructors are called
> where the memory used to store objects are recycled.
>
> The former is more `manual' and more predictable in terms of when things
> happen. The latter more automatic and (I think) imposes the rule that every
> object on the free store must be destroyed on normal program termination.
This seems backwards. If the semantics of your class requires that
every object which is created be destroyed before program termination,
then objects that remain in the free store at program termination must
be destroyed and objects that are reclaimed by GC must also be
destroyed. [The former can be arranged pretty easily by chaining all
objects of the class together and appointing a static object (of
another class) to destroy anything left on the chain when it is
destroyed.] If the semantics of the class allows objects to be simply
abandoned when they will no longer be used then they can be left in
the free store when the program terminates and GC can recycle the
object's memory when the object is inaccessible.
An example of a class whose semnantics require that every object be
destroyed is a file class where the destructor flushes an internal
buffer, and an example of a class whose semantics allow objects to be
abandoned is a list whose destructor deletes the elements of the list.
The `automatic destruction' model is suitable for both kinds of classes.
If you have an `infinite memory' model GC and you have a class whose
objects cannot be simply abandoned, you must be sure not to lose
any of them. I actually don't think this is a very heavy requirement,
because (I think) such classes are not very common, and when they are
used, not many instances are created. The heavy requirement is, as
usual, you have to know what you are doing.
--
Jonathan Shopiro
AT&T Bell Laboratories, Warren, NJ 07060-0908
research!shopiro (201) 580-4229
Jim Patterson
>In article <1...@eiffel.UUCP> Bertrand Meyer (bert...@eiffel.UUCP)
>follows up to provide a (patch) solution:
>
>> In version 2.2 the library class MEMORY will include an argumentless
>> procedure called dispose, to be invoked by the garbage collector (if
>> active) when an object is freed.
>
>don't see that it should be the final answer. An "obvious" solution
>might be to imbue Eiffel's `Forget' with an enlarged semantics, thus
>moving the solution under the auspices of the language definition and
>away from all the ad hoccery involving strange class inheritences. I
>would propose that programmers could define their own `Forget'
>routines analogously to programmer-defined `Create's.
This suggestion ignores the significant difference between Eiffel's
Forget builtin feature and more direct memory management primitives
such as C's free. Forget simply clears a reference to an object; it's
still left up to the garbage collector to actually free the object,
and then only if there are not other references. If Forget were
changed to actually dispose of the object (or to perform cleanup
code), then other references to that object within the program
would suddenly became invalid. This negates the major benefit of
a garbage collector, which is to relieve the programmer of the
burden of tracking which objects are or are not still accessable.
Dispose is the more appropriate solution, as it supports an arbitrary
number of references to any object so that the Dispose procedure
is only actually called when there are no remaining references.
One drawback is that the actual timing of a Dispose call is somewhat
arbitrary; this must be considered when designing the class.
--
Jim Patterson Cognos Incorporated
UUCP:decvax!utzoo!dciem!nrcaer!cognos!jimp P.O. BOX 9707
PHONE:(613)738-1440 3755 Riverside Drive
Ottawa, Ont K1G 3Z4
nevin.j.liber
>I don't have my OOSC around at the moment, but far as I recall Eiffel
>does give you a choice. You can turn off garbage collection if you
>absolutely have to.
But doesn't this affect class (or whatever the equivalent of "class" is
in Eiffel) design? I, for would, would design differently based on
whether there was GC or not. Is this done globally or on a
class-by-class basis? There are problems with either approach. If it
is global, some classes may die because there is nothing reclaiming
memory. If it is on a class-by-class basis, I have to avoid all
classes which might possibly use GC, or it really isn't "turned off"
for my class.
--
NEVIN ":-)" LIBER AT&T Bell Laboratories nev...@ihlpb.ATT.COM (312) 979-4751
nevin.j.liber
|You seem to be suggesting that malloc()/free() is more controllable than
|malloc()/garbage collection. If so, then in what sense??
|Garbage collection can be time-consuming, of course, but so can free().
But free() is more predictable. In many current schemes, you never
know exactly when GC will take place, or how long it will take.
|If you have a language with garbage collection, it is usually very easy
|to ensure that no garbage collection gets performed in some critical
|section by simply not allocating any memory.
What if I *need* to allocate memory in a critical section? Stopping GC
for some-of-the-time is not a trivial issue.
H.Dr.Ehling
discussion in this group -- could someone please mail me a pointer to a
UUCP accessible source of that programm ?
Many Thanks,
Juergen Ehling
--
Hans-Juergen Ehling | Europe: e...@astbe.uucp, USA: ...!pyramid!tub!astbe!eh
| Voice: +49 30/828-2497 Fax: +49 30/828-2483
GEI Software-Technik, Hohenzollerndamm 150, D1000 Berlin 33, FRG
Larry Campbell
-> (true) even though by suitable hackery you can graft it in;
-
-(false.) Overloading "new" and "delete" constitute C++ support for GC in
-my opinion, since I can now attach the GC scheme of my choice where I want
-it when I want it. Either as a global decision, or on a class by class basis.
Nope. How do you find the garbage? Overloading new() and delete() won't
find garbage for you. I can easily lose a pointer to an object without
calling delete() on it.
Patrick C Beard
__________________
Patrick Beard
PCB...@lbl.gov
BSI, Berkeley, CA
___________________
Norman Diamond
>There is an important question that needs to be asked in regards to GC
>of C++ programs:
> ``When an object is garbage collected should its destructor
> (if any) be called?''
Perhaps an alternative destructor should be called. Perhaps its name
could be !classname(). The reason for an alternative destructor is
that the user might not have expected "leaks" but wishes to be prepared
to do debugging. If a user expects garbage collection as normal for a
class, then !classname() might invoke ~classname(), uh, er, or they
might both invoke the same "helper" routine.
Jim Adcock
>
> (1) the `infinite memory' model where destructors are only called
> for explicitly deleted objects, and
> (2) the `automatic destruction' model where destructors are called
> where the memory used to store objects are recycled.
>
Seems to me the two models can, and maybe must, coexists. Seems like to get
a destructor called when a lost object is found, one would want to have a
virtual destructor. To know that an object has a destructor, and where in
the vtable the destructor is, the GC is going to need some info about a class
of an object. Which is going to require some cooperation between a class and
a GC. A simple "solution" is to have objects who need to have destructors
called when found be derived from some gc_base_class, where gc_base_class
objects can be identified as such by the GC, and have a destructor protocol
understood by the GC. Lacking this knowledge about an object, the GC wouldn't
know enough to be able to call a destructor [if one exists.]
Certainly there are other ways of doing this, that wouldn't need vtable
pointers -- for example objects of a certain type could be allocated from
pools, where the type of the pool is known to the GC. This still requires
cooperation from the GC.
Anyway, classes thus fall naturally into two categories -- those that cooperate
with a GC, and those that don't. If you want your class to have destructors
called by a GC, it will have to cooperate with that GC, otherwise no
destructors will be called.
It would be nice if people who are writing GCs write them in such a way that
they can coexist with other memory managers [Boehm's claims this capability.]
Then a choice of GC could be considered part of a class writer's design
decisions. A GC that locks out other GCs then would be considered a bad
design.
Hans Boehm
The garbage collector has been sent for posting to comp.sources.unix.
I do not know where it is in that queue. In the meantime it can be obtained
by anonymous ftp from
titan.rice.edu:~ftp/public/gc.shar.0[12]
or by sending the following two messages to archive...@rice.edu:
send public gc.shar.01
send public gc.shar.02
I believe the problem that Jim Adcock recently wrote about is tracable
to essentially infinite recursion in the program itself. The collector
happened to be the piece of code that actually exceeded the stack limit.
(I'm sure lots of people will correct me if I'm wrong ...)
The collector is not completely portable, though it comes reasonably close,
at least for machines with 32 bit pointers. You do still need to specify
constants like the starting address of the stack,
and a few others. On some machines you need to specify a few lines of
assembly code to mark from certain registers. It currently runs on
VAXen, some HP machines, SUNs, PC/RTs, MIPS M/120s and a few others.
The approach does work much better in sparsely populated address spaces.
It works fine on an 80386 based Sequent machine. I suspect it won't work
very well in an MS-DOS environment with 16 bit pointers. (As distributed,
it won't work at all in this environment, for several reasons.)
There are currently no hooks for invoking destructors or the like. All
that is supplied are malloc and free replacements and a number of hooks for
performance tuning.
This collector is copyrighted, but the restrictions imposed are rather
liberal. They are not intended to prevent redistribution.
Hans-J. Boehm
bo...@rice.edu
Jim Adcock
> In article <659...@hplsla.HP.COM> ji...@hplsla.HP.COM (Jim Adcock) writes:
> -> What I should have said is that "there is no language support for GC in C++"
> -> (true) even though by suitable hackery you can graft it in;
> -
> -(false.) Overloading "new" and "delete" constitute C++ support for GC in
> -my opinion, since I can now attach the GC scheme of my choice where I want
> -it when I want it. Either as a global decision, or on a class by class basis.
>
> Nope. How do you find the garbage? Overloading new() and delete() won't
> find garbage for you. I can easily lose a pointer to an object without
> calling delete() on it.
Yep. ::Delete only gets used if the user doesn't lose an object, and/or
explicetely deletes it. Otherwise the GC finds and deletes lost objects.
In my example ::new calls Boehm's gc_alloc and ::delete calls Boehm's gc_free,
with essentially the same meanings as the standard C malloc and free,
except that at "appropriate" times gc_alloc calls the GC or increases heap
space based on a heuristic algorithm. I believe gc_free returns an object
to free space, maybe makes some marks, and updates the statistics gc_alloc
uses to determine when to increase heap space or garbage collect.
My overloading ::delete was just another example of the general rule that
whenever one overloads a new, one should overload the matching delete. This
is independent of whether one is losing objects or not, or whether one is
using a GC. Sorry I didn't make this more clear.
Bertrand Meyer
quoted by later messages:
>> For me, Eiffel was kind of like a chastity belt. It definitely keeps
>> you "pure" but you will probably have less fun.
>> It struck me, in fact, that a good many of [B. Meyer]'s comparisons between
>> C++ and Eiffel boiled down to "C++ lets the programmer foul things up in
>> any way he pleases, while Eiffel insists on doing it right". This is, in
>> fact, a long-standing philosophical difference between the C camp and the
>> Pascal camp.
The debate, which is older and broader than the question of C versus
Pascal, is indeed an important one: How restrictive and prescriptive
may a language designer be in forcing a particular approach to software
construction upon the users of the language?
However their application to the design of Eiffel may be judged,
I can at least clarify my intentions.
1. ``Chastity belts'' are inappropriate. A chastity belt prevents its
holder from doing things that are desirable and enjoyable. A language
designer is not a guardian of moral order.
2. A good programming language is one that helps programmers write good
programs. No programming language will prevent its users from writing bad
programs.
[If I recall correctly, this is an observation I first heard
a long time ago from Kees Koster, who among other things
is the designer of the CDL language.]
3. Some constructs are known to be dangerous, meaning that programs
employing them are prone to contain damaging errors.
In any language meant for industrial production, it is the language
designer's responsibility to exclude such constructs.
Examples include type casts, user-controlled memory deallocation,
pointer arithmetic, in-line functions (in an object-oriented language)
etc.
4. The purpose of excluding a construct is not to prevent
programmers from writing bad programs or doing ``dangerous things'' if
they want to. (See points 1 and 2.) Instead, a construct is excluded
because it is known to lead programmers to make mistakes even when
applied towards legitimate goals.
This highlights the basis for all this discussion. In the same way
that the author of a novel has a typical reader in mind, the designer
of a programming language is, consciously or not, designing for
a typical programmer. We should assume (as was done for Eiffel)
that this typical programmer is intelligent and reasonable.
The restrictive parts of the language design are not meant to prevent
the programmer from being ``bad'', but rather to help him avoid
known pitfalls and involuntary mistakes.
5. For the language designer, excluding a construct is not a solution
but a problem.
In all likelihood the excluded construct addressed some legitimate
need, albeit in an inadequate way. The designer must find a better
technique to satisfy the same need. This is the difficult part, of course:
exclusion is easy. Sometimes the solution is a better programming
language construct; in other cases the problem is best handled by the
implementation (compiler and programming environment).
For example, unrestrained type casts may be replaced by
inheritance-controlled polymorphism; garbage collection should be under
the control of the run-time system; pointer arithmetic is unneeded in the
presence of type-safe dynamic binding; and in-line routine expansion
should be the responsibility of an optimizing compiler.
6. Literal compatibility with previous languages should not be a
criterion. People will learn a new language quickly if its design is
simple and consistent. One should learn from the mistakes of the past, not
perpetuate them.
Some care should be exercised, however, when one deals with programmers'
current habits. For example, a new language should not use an existing
notation in a way that confusingly departs from its accepted semantics.
(The Eiffel assignment operator, :=, is a case in point;
its semantics would probably have been different were it not for the fear
of confusing Algol-Pascal-Ada programmers.)
7. Perhaps my major personal guideline is to maximize the signal-to-noise
ratio of the language.
Exclude constructs that just add complexity to the language without
bringing any significant new possibility (for example, varieties of
loops); include constructs that tersely and elegantly address a large number
of practical situations.
8. Any occurrence in a language description of a sentence of the form
``Be careful when using this construct'' implying that its use may have
dangerous consequences, is an avowal of failure on the designer's part.
Programmers should be encouraged to use the entire language, not a subset.
The programming language is the software developers' fundamental tool.
They should know, love and trust all of it.
9. Hard as you try to maximize the signal-to-noise ratio, there may remain
cases in which special needs require special facilities.
Such special facilities should be limited to only one situation:
the need to access low-level internal or machine-dependent elements.
In my opinion, this is best addressed by techniques that
fall outside of the language proper, such as machine-code insertions in
Ada or external routines in Eiffel.
To avoid violating the previous criterion (8), there should be very
few such techniques, and they should never be needed in normal uses
of the language. In Eiffel their typical uses have been encapsulated in
the library (essentially in the class called INTERNAL) and their application
is limited to the following cases:
- Interfacing with elements on which the language design has no
control: existing software tools (for example, relational data base
management systems) or software written in other languages.
- Machine-dependent programming.
- Implementation of facilities which are part of the basic environment
(such as the ARRAY and STRING classes in the kernel Eiffel library).
- Facilities which the language designer feels are not necessary, while
recognizing that some language users may disagree on this point. There
is one example of this in Eiffel: class INTERNAL contains a procedure
``free'' which will explicitly return an object to the free store.
In our opinion it should never be used, and none of our own software
ever uses it; however we accept that some users may disagree and would
rather provide the corresponding facility in an ``official'' form
than encourage these users to fool around with internal formats.
***
In summary, the aim of what Mr. Guilmette calls a more ``pure'' design
is not to prevent programmers from ``fouling things up'' but to enable them to
do things in a way that is at the same time safer, more elegant, more
powerful and more convenient. Reconciling these goals is the main challenge
in designing a better programming language.
Coming back to the first two lines of his extract:
>> For me, Eiffel was kind of like a chastity belt. It definitely keeps
>> you "pure" but you will probably have less fun.
Eiffel programmers can have fun, too, thank you. Of course, someone whose idea
of fun is to spend his or her nights debugging will have less of it.
But then such a person wouldn't need a chastity belt anyway.
-- Bertrand Meyer
bert...@eiffel.com
Jim Adcock
> for some-of-the-time is not a trivial issue.
Depends on the design goals of the GC. Traditionally GCs were invoked when
one "runs out of memory." Turning off GC in this scenerio doesn't help one
do critical paths, if one still needs memory.
Boehm's GC has the easier -- and on virtual memory machines -- the more
reasonable goal of reducing the growth of heap space. So one can "always"
turn off GC for a while -- it just means heap might grow on you. If your
critical path can't afford to wait while the O.S. grows heap space, then
you can explicitely grow heap space before entering your critical region.
Still, one needs a programming task that can afford several seconds time
out occasionally. Strict "real-time" systems may not be able to handle
this.
Terry Domae <tdomae>
Quibbling about the relative brain-damage of these languages just
serves to produce heat, and no light. It is sufficient to say that each
of these languages have problems, and list out these problems.
Every language has applications which are implimented faster, better,
or more efficiently than other languages. C++ and Eiffel are no different!
I think this whole discussion came about because someone wanted to understand
what each of these languages are good for. I've not seen a good summary yet.
In fact, it's been so long since I saw the original message, I don't remember
who submitted it. And, it's been flushed from our news-server. Also, the
bashing that's going on in this group really dilutes its usefullness.
I'd also like to ask if anyone is using David Unger's Language `self'
(from Stanford). And if not, how do people perceive the relative strengths
and weekness of `self'. I'd like OBJECTIVE, FACTUAL, and CLEAN experiences
(free of this name calling) -- In other works TECHNICAL! Opinion is nice
too as long as it's keeped professional.
-- A Small Rock Thrown at Eiffel Here, but FACTUAL AND OBJECTIVE!
-- An Eiffel Implementation Problem:
--
-- I'd just like to note that I tried Eiffel at the ICSE (International
-- Conference on Software Engineering) after reading the book, and the
-- environment crashed (dumped core) many times for no real reason.
-- It seems that the Eiffel environment might need a bit more debugging
-- and less philosophy right now.
Terry Domae
Northrop Research and Technology Center
Terry Domae
Jim Adcock
>to essentially infinite recursion in the program itself. The collector
>happened to be the piece of code that actually exceeded the stack limit.
>(I'm sure lots of people will correct me if I'm wrong ...)
I also believe the problem was in my program. Sorry. [I provided more
details in a previous retraction.]
nevin.j.liber
of the points; I am mainly commenting on those I disagree with.
In article <1...@eiffel.UUCP> bert...@eiffel.UUCP (Bertrand Meyer) writes:
|3. Some constructs are known to be dangerous, meaning that programs
|employing them are prone to contain damaging errors.
|In any language meant for industrial production, it is the language
|designer's responsibility to exclude such constructs.
| Examples include type casts, user-controlled memory deallocation,
|pointer arithmetic, in-line functions (in an object-oriented language)
|etc.
Unfortunately, stuff like type casts and user-controlled memory
management tend to be useful in many contexts.
|4. The purpose of excluding a construct is not to prevent
|programmers from writing bad programs or doing ``dangerous things'' if
|they want to. (See points 1 and 2.) Instead, a construct is excluded
|because it is known to lead programmers to make mistakes even when
|applied towards legitimate goals.
But, as a USER, I really don't care what the *purpose* behind doing
something is. For example, the *purpose* behind putting in ramps in
sidewalks wasn't to allow kids to ride their bicycles into traffic
without having to stop like they had to for curbs, yet that was the
*result*.
|The restrictive parts of the language design are not meant to prevent
|the programmer from being ``bad'', but rather to help him avoid
|known pitfalls and involuntary mistakes.
But they DO prevent the programmer from being ``bad''; that is the
price that is being paid in order to help him avoid known pitfalls and
involuntary mistakes.
|6. Literal compatibility with previous languages should not be a
|criterion. People will learn a new language quickly if its design is
|simple and consistent. One should learn from the mistakes of the past, not
|perpetuate them.
| Some care should be exercised, however, when one deals with programmers'
|current habits. For example, a new language should not use an existing
|notation in a way that confusingly departs from its accepted semantics.
|(The Eiffel assignment operator, :=, is a case in point;
|its semantics would probably have been different were it not for the fear
|of confusing Algol-Pascal-Ada programmers.)
Keeping 6 in mind, and assuming that you wanted to give the Eiffel
assignment operator different semantics than those given by
Algol/Pascal/Ada to ":=", why didn't you just pick another symbol (eg:
".=")? Please elaborate.
|7. Perhaps my major personal guideline is to maximize the signal-to-noise
|ratio of the language.
| Exclude constructs that just add complexity to the language without
|bringing any significant new possibility (for example, varieties of
|loops); include constructs that tersely and elegantly address a large number
|of practical situations.
But varieties of loops, if used correctly (admittedly, a big if), can
add to the self-documenting aspect of a language.
This whole discussion reminds me of an early paper by Wirth which I
read a while back (I wish I could find that paper :-(). In it, he
spends the first half describing his ideal programming language, which,
to me, seemed close to C, and then spent the second half saying that it
was unusable because you couldn't guarantee safety.
David Chase
>
>There is an important question that needs to be asked in regards to GC
>of C++ programs:
>
> ``When an object is garbage collected should its destructor
> (if any) be called?''
>
>People often simply assume that the answer is `yes.'
>
>This is not obvious.
[and goes on to point out that if the answer is yes, then "normal
program termination" will require a round of destructor-calling.]
Two other problems also appear. The first occurred to me when this
was discussed (in general terms) for Modula-3, and the other was
pointed out by people at Xerox PARC working on PCR.
(1) if a cyclic pointer graph is collected, there is really no way
for the collector to know which object's "destructor" should be called
first. Barring interesting restrictions on what can be done in a
destructor, the collector could easily get this wrong.
(2) invocation of destructors ("finalization", to use the PARC/Cedar
terminology) on unreachable objects interferes with timely garbage
collection. This is so because (assuming a non-cyclic pointer graph)
the objects referenced by a finalized object cannot be collected until
after finalization; the destructor might also wish to refer to those
objects. If few objects are marked for finalization, then
this won't seriously degrade the performance of the collector. If,
however, every single "object" collected must have its destructor
called before it can be recycled, then memory will be returned to the
free list more slowly. This depends on the shape of the graphs which
become garbage, however -- balanced trees of N nodes will be recycled
in roughly log N collections, but lists (degenerate trees) of N nodes
will require N collections before they are completely recycled.
Make of this what you will. For C++, it looks like the issue is "do
we really want garbage collection?" For Modula-3, the question is
instead "do we really want finalization"?
Some time was briefly spent designing a finalizing copying-compacting
garbage collector. If the page protection games are played [*], then
it looks (informally) like finalization might be more practical in a
compacting collector. Of course, such a collector cannot be used with
ordinary C compiled by ordinary C compilers.
David
[*] See work by
Appel, Ellis, and Li (SIGPLAN '88, Atlanta)
Appel and MacQueen (Func. Prog. Lang. and Comp. Arch '87, Portland)
Bartlett (DEC WRL tech report, I believe)
discussing use of page protection to help implement copying-compacting
collectors on "stock hardware".
Bertrand Meyer
[Quoting from my previous message: ]
> | Some care should be exercised, however, when one deals with programmers'
> |current habits. For example, a new language should not use an existing
> |notation in a way that confusingly departs from its accepted semantics.
> |(The Eiffel assignment operator, :=, is a case in point;
> |its semantics would probably have been different were it not for the fear
> |of confusing Algol-Pascal-Ada programmers.)
> [...] Assuming that you wanted to give the Eiffel
> assignment operator different semantics than those given by
> Algol/Pascal/Ada to ":=", why didn't you just pick another symbol (eg:
> ".=")? Please elaborate.
[Perhaps :-) would do for assignment?] :-)
Actually the Eiffel convention is the same as the Pascal and Ada
ones for entities of pointer/access/reference types, which is the reason
for keeping the same notation.
In general it seems proper to avoid inventing a new notation
where there is no real semantic innovation and a widely accepted notation
exists, unless there are strong arguments against that notation. (An
example of the latter would be the Fortran/C use of = for assignment,
which conflicts with time-honored mathematical conventions.)
The language should look familiar in places where the concepts are indeed
familiar. There are a number of novel ideas in Eiffel, but assignment
is a quite standard concept. As one may expect, the properties of
assignment in Eiffel are not identical to those of its counterparts in
previous languages, but the differences do not seem big enough to warrant
a totally new notation. Call it lack of courage if you will.
-- Bertrand Meyer
bert...@eiffel.com
Jim Adcock
>we really want garbage collection?" For Modula-3, the question is
>instead "do we really want finalization"?
Again, I would hope GC is not going to become a "built-in" feature of
C++, but rather, like streams, a standard library that people can choose
to use or not choose. Then, like any other library, a GC that prohibits
the use of other GC libraries would be a bad design. And general purpose
classes that aren't tied to a particular GC would be better than ones that
are. And classes that don't need GC would still be the ones most widely
applicable, reusable, and therefore "best." I hope these issues can continue
to be decided on a class-by-class basis.
Piercarlo Grandi
From <15...@cbnewsc.ATT.COM> by nev...@cbnewsc.ATT.COM (nevin.j.liber):
> [...] Assuming that you wanted to give the Eiffel
> assignment operator different semantics than those given by
> Algol/Pascal/Ada to ":=", why didn't you just pick another symbol (eg:
> ".=")? Please elaborate.
[Perhaps :-) would do for assignment?] :-)
Remember this line for later on...
Actually the Eiffel convention is the same as the Pascal and Ada
ones for entities of pointer/access/reference types, which is the reason
for keeping the same notation.
Ugh. I beg to differ. Pascal and Ada have a concept of pointer,
and indeed := is used by them to do *copy* of pointer objects. This
is VERY different from Eiffel. The analogy cannot hold.
In general it seems proper to avoid inventing a new notation
where there is no real semantic innovation and a widely accepted notation
exists, unless there are strong arguments against that notation.
Eiffel, by doing without a concept of pointer (except by hack)
and by having reference and copy assignments both under := blurs
the distinction between EQ and EQUAL, that lispers know as being
very fundamental.
As one may expect, the properties of assignment in Eiffel are not
identical to those of its counterparts in previous languages, but
the differences do not seem big enough to warrant a totally new
notation. Call it lack of courage if you will.
Ahhh! Let me exhume old ghosts... Simula67 uses := for
assignment, and :- for reference assignment. You would have
invented nothing new, and adopted a well known tradition, if you
had used :- for reference (in the Simula67 sense) assignment.
Also, I am incredibly amused by the idea that actually :- *is* the
leading part of :-)...
NOTE: I find it worrying that the author of Eiffel, a person that
I greatly esteem, is not extremely familiar with Simula67 and Lisp.
Now some embarassing questions: Has he ever read the Simula67
Common Base standard? Simula BEGIN? What is Hash Consing and how
does it relate to this discussion? What is rplac[ad] and how does
it relate to this discussion?
NOTE on NOTE: many will have noted (:->) that one of my pet
peeves is moaning about the lack of historical perspective
by most computer scientists (especially, let me say, American
(ised :->) ones wrt much European research). I apologise
in advance for the irritation this mania causes...
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.abe...@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: p...@cs.aber.ac.uk
Marvin Solomon
(Piercarlo Grandi) discusses the Simula 67 ':-' operator and how it relates
to ':='. (His note contains quotes several levels deep, and it wasn't clear
to me who wrote what, so I won't quote him here). I've come to realize that
there is a basic concept here that can be used to classify languages and
clarify their semantics.
In 1975 I mentioned to a grad student at the University of Aarhus (Denmark)
that I found the distinction between :- and := in Simula very confusing.
It seemed to me that you used :- to assign pointers and := to assign
anything else. The student, who was an acolyte of Christian Nygaard, one of
the chief gurus of Simula, heatedly informed me that Simula doesn't have
pointers, only references, and A REFERENCE IS NOT A POINTER!!. After
a bit of arguing, I came to realize that he and I had different pictures
in our heads when we wrote
ref(foo) p;
Consider what it means to declare (in C or C++)
int i = 3;
This allocates a cell big enough to hold an integer, puts a three into the
cell, and binds the identifier 'i' to it. The picture is
+---+
i : | 3 |
+---+
Now consider the definition
int *p = &i;
This allocates a cell big enough for an address, binds 'p' to it, and
initializes it with the address of the cell bound to i. The picture is
+---+
p : | *--------+
+---+ |
v
+---+
i : | 3 |
+---+
Given this picture, the C assignment operator '=' always means "copy":
In the expression 'e1 = e2', the expression 'e1' must evaluate to an
'lvalue'--i.e., it must designate a cell--and e2 must evaluate to a value
of the right size and shape to fit into the cell. A copy of the value
of e2 is put into the cell denoted by e1.
Now consider the Simula statements
ref(integer) p,q;
p :- new integer;
q :- p;
If you view the Simula 'ref(integer)' as a synonym for the C 'int *',
it would appear that the "assignment" operator :- has copy semantics.
If so, why are there two operators :- and := in Simula? In fact, in almost
every case only one of
p :-
or p :=
is legal, depending on the type of p. The lone exception concerns the type
'text', which is a built-in character-string type. More on this later.
As it turned out, my informant had quite a different picture in his mind.
To him, a reference is a kind of movable label for a cell. For the fragment
of Simula above, he would draw the picture
+---+
p: | |
q: | |
+---+
Thus := means "copy the contents", whereas :- means "move a label".
Restrictions on when :- or := is legal can be thought of as implementation
limitations rather than fundamental semantics concepts. For example,
integer i;
ref(integer) p;
p :- i;
p := 3;
is not allowed, but if it were, it would lead to the picture
+---+
p: | 3 |
i: | |
+---+
In the case of 'text', both :- and := are allowed, and the semantics follows
this pattern:
text t,u,v;
t := "hello";
u :- t; comment u refers to the same string as t;
v := t; comment v refers to a copy;
t[1] := "H";
comment Now t=u="Hello" and v="hello";
[DISCLAIMER: I may not have the Simula syntax exactly right. It's been
over 10 years since I've used the language and I don't have a manual handy.
But I'm pretty sure I have the semantics right.]
C++ aficianados will note the similarity of Simula "references" and C++
"references". References in C++ are probably one of its most obscure and
confusing features for C programmers. The confusion is exacerbated by the
fact that C++ has *both* pointers and references and by the fact that
the same symbol (=) is used for copy (in the context of an assignent) and
reference binding (in the context of an initialization). Consider
int i,j;
int *p;
int &jj = j;
p = &i;
*p = 3;
jj = 4;
The picture is
+---+ +---+
p : | *--------+ j: | 4 |
+---+ | jj: | |
v +---+
+---+
i : | 3 |
+---+
In the introduction to this note, I promised a classification of languages.
The classification concerns nesting of data structures; it is most easily
described in implementation terms: Can a data structure contain instances
of other data strucutres, pointers to data structures, both, or neither?
FORTRAN is a langauge that does not admit nested structures at all.
COBOL allows nesting of structures, but does not support pointers.
LISP, Simula, SmallTalk, and CLU are all examples of languages that allow
data structures to contain pointers, but not actual instances (copies)
of data structures. I gather from discussions in this group that Eiffel
falls into this category, although I do no know Eiffel well enough to be sure.
The fourth class of languages all seem to trace their descent from a languauge
called CPL (or perhaps Algol 68, which was designed about the same time).
They include PL/I, Algol W, Pascal, BCPL, C, and C++. These allow a
"subobject" to be represented either by a local copy or by a pointer.
The programmer is require to choose the representation.
In all but the last class of languages, the distinction between a pointer
and a local copy can be largely hidden by the syntax and operational semantics
of the language, and by introducing limitations on how language primitives
can be combined. For example, compare C++ with Simula:
C++ Simula
--- ------
class foo { int a,b,c; }; class foo; begin integer a,b,c; end;
foo *p; ref(foo) p;
foo f; foo f; comment illegal;
p = new foo; p :- new foo;
(*p).a = 5; p.a := 5;
f.a = 6; comment no counterpart;
In this respect at least, Pascal is like C++. The equivalent program is
type foo = record a,b,c : integer end;
var p : ^foo;
f : foo;
begin
new(p);
p^.a := 5;
f.a := 6;
end;
Since the Simula programmercannot get his hand directly on an instance, but
only a reference, the dot notation can be used unambiguously to mean
"dereference the pointer and index into the resulting structure" (or
"access the structure referred to by the reference", depending on your point
of view). In C and Pascal, a finer distinction is made between an object
and a reference to it (this is a from of the "use/mention" distinction familiar
to linguists: "the name of the song is called..."). Pointers must be
explicitly dereferenced before selection. The syntax is clumsy enough
in C that the '->' operator was introduced as an abbreviation (no such
abbreviation is required in Pascal because "dereference" is a postfix operator).
The distinction between a pointer and a copy has important implications for
time and space efficency. Consider
struct large { char data[1000]; };
struct large hello = {"hello"};
struct large goodbye = {"goodbye"};
struct {
struct large a;
struct large *b;
} f,g;
char c;
f.a = hello; // slow
f.b = &goodbye; // fast
g = f; // g.a=f.a (slow); g.b=f.b (fast)
c = f.a.data[0]; // very fast (one memory reference)
c = f.b->data[0] // possibly two memory references
It also has important semantic ramifications in three contexts:
update, comparison, and deletion.
Structure-sharing can cause anomalous behavior in the presense of updates.
f.a.data[0] = '*';
f.b->data[0] = '*';
puts(g.a.data); // "hello"
puts(g.b->data); // "*oodbye"
This is the infamous "alias problem". (Pure) LISP avoids the problem by
disallowing update-in-place. In other languages, it causes no end of
headaches for (optimizing) compiler writers and serious pitfalls for
programmers. Teaching introductory data structures in Simula in the late
70's, I found this alias problem to be one of the worst sources of bugs
in students' programs. ("Look, I print this message before calling f and
after the return and it changes, even though I don't pass it as a parameter!").
Comparison leads to the EQ vs EQUAL distinction mentioned in a previous note.
struct { char *a; } f,g;
f.a = "hello";
g.a = "hello";
bcmp(&f, &g, sizeof f); // returns false!
Deletion brings us to the subject of garbage collection, which has already
been beated to death in this group. I have two cents to contribute to
this question too, but I've already rambled on far too long, so I'll restrain
myself.
In summary, structure-sharing is dangerous, but so absolutely essential
in so many applications that is cannot be left out of a language. In cases
where the programmer chooses not to share, however, there is no reason
to suffer the additional time and space overhead of a pointer.
This sort of low-level efficiency question would be better left to
the compiler, but until we have compilers for "real" languages that can do
complete alias analysis (I've been waiting 20 years now), I'm afraid
the programmer is still going to be asked to lend a hand.
--
Marvin Solomon
Computer Sciences Department
University of Wisconsin, Madison WI
sol...@cs.wisc.edu, ...seismo!uwvax!solomon
Bertrand Meyer
> Pascal and Ada have a concept of pointer,
> and indeed := is used by them to do *copy* of pointer objects. This
> is VERY different from Eiffel.
Unless there is something I don't understand I am afraid Mr. Grandi
is mistaken. Both in Pascal and in Ada := is used for pointer assignment.
For Pascal, see chapter 10 of Pascal User Manual by Kathleen Jensen and
Niklaus Wirth, Springer-Verlag, 1974 (pages 62-66 in the second edition);
also the ``Report'' part of the same book, section 7.3. For Ada, the relevant
section of the Reference Manual (3.8) is not the most luminous piece of
technical literature ever written, but there is no doubt that the semantics
is indeed that of pointer assignment. (See for example ``Ada for Experienced
Programmers'' by A. Nico Habermann and Dewayne E. Perry, Addison-Wesley,
1983, page 197.)
Interestingly enough, Pascal and Ada both also use := to prescribe value
assignment for referenced records. I believe the correct notations are
p^ := q^ in Pascal and p.all := q.all in Ada.
As explained in my article on ``Eiffel types'', there are cases in
which one *explicitly wants* to have the same symbol express different
semantics for reference types and expanded types. (The latter is Eiffel 2.2
terminology for types whose elements are objects rather than references to
objects; expanded types include the basic types INTEGER, REAL, DOUBLE etc.)
Thanks to expanded types and the associated assignment and
argument passing conventions, Eiffel 2.2 allows programmers to choose
exactly what they need in a given case: uniform copy semantics, or
variable semantics. This is particularly important for generic classes.
> I find it worrying that the author of Eiffel [...]
> is not extremely familiar with Simula67 and Lisp.
> Now some embar[r]assing questions: Has he ever read the Simula67
> Common Base standard? Simula BEGIN? What is Hash Consing and how
> does it relate to this discussion? What is rplac[ad] and how does
> it relate to this discussion?
>
This is an interesting idea: Usenet as an ongoing certification program,
or people's tribunal (``You don't even know the basics!'', shouts the Red
Guard to the Mandarin). It is tempting to reply, as Mitterrand to
Giscard d'Estaing during the 1981 presidential debate,
``I am not your student, and you are not my professor'',
but let me not be stuffy and indeed answer.
The author of Eiffel did write more than a few Lisp and Simula
programs, thank you. One of my first programming courses
was a Lisp course taught by Prof. John McCarthy; I remember him as
reasonably competent on the subject. On Simula, please see
``Quelques concepts importants des langages de programmation modernes,
et leur expression en Simula 67'', by the undersigned, GROPLAN 9, AFCET,
1979. (English version presented at the Tenth Conference of the
Association of Simula Users, Oslo, in, I believe, 1980 or 1981.)
As to rplaca and rplacd, the definition I am tempted to give is
``If you like the idea of functional programming, the main arguments
for using Miranda rather than Lisp''.
-- Bertrand Meyer
bert...@eiffel.com
Paul Hudson
discussion seems to be *about* the GC arguments ;=) All together now:
"Let's drop ... "
(Yes, I know, this is a dreadful waste of the net bandwidth).
--
Paul Hudson MAIL: Monotype ADG, Science Park, Cambridge, CB4 4FQ, UK.
PHONE: +44 (223) 420018 EMAIL: pa...@moncam.co.uk,
;" FAX: +44 (223) 420911 ...!ukc!acorn!moncam!paul
`"";";" "/dev/null full: please empty the bit bucket"
mo@prisma
An ounce of garbage prevention is worth pounds and pounds of
garbage collection.
If you design with garbage management in mind, you discover
you don't really miss a GC. On the contrary, I've seen
lots of programs that work only BECAUSE the GC lets dangling
pointers continue to work.
This is actually quite humorous - the LISP folks have discovered
that after they get their algorithms right, if they rewrite their
inference grinders in C with good garbage prevetion and management,
they get dramatic speed improvements. And here we have the C folks
going the other way.
Isn't life strange....
David Chase
>Modula-3, by contrast, allows you to decide on a type-by-type basis whether
>objects of the type are to be GC'd or not. This seems to me to be the best
>solution.
To be fair, this is only somewhat the case. In code that is
explicitly declared as UNSAFE you are allowed to choose on a
type-by-type basis whether or not objects are GC'd or not. In
practice, most code should *not* be unsafe (though some very important
code will be unsafe), and writing unsafe code places a much greater
burden on the programmer. It really isn't much different from writing
C, except that many more errors become the fault of the programmer,
and the run-time system is not really tuned to make life easy for the
author of unsafe code.
For example, if you store a pointer to garbage-collected memory in a
record field that is declared to be an INTEGER, the memory could be
reused. That's a programmer error. If you store a pointer to gc
memory at an unapproved offset (i.e., odd byte alignment), the memory
could be reused. That's a programmer error. If you write unsafe
code, then it is presumed (as so many C programmers are quick to
claim) that you know what you are doing.
David
nadk...@ashok.dec.com
>In article <7...@redsox.bsw.com> camp...@redsox.UUCP (Larry Campbell) writes:
>>Modula-3, by contrast, allows you to decide on a type-by-type basis whether
>>objects of the type are to be GC'd or not. This seems to me to be the best
>>solution.
>
>To be fair, this is only somewhat the case. In code that is
>explicitly declared as UNSAFE you are allowed to choose on a
>type-by-type basis whether or not objects are GC'd or not. In
>
>David
Not true as far as I recall. If I remember the report correctly, you CAN decide
on a type by type basis whether to GC or not. The UNTRACED keyword is provided
for this purpose. This is true even for SAFE modules. What you might be
referring to is that untraced REFs can point to traced REFs (or is it the other
way around ?) only in UNSAFE modules.
Of course, I've done little more than glance through the language definition
so I might be wrong.
/Ashok
David Chase
>>>Modula-3, by contrast, allows you to decide on a type-by-type basis whether
>>>objects of the type are to be GC'd or not. This seems to me to be the best
>>>solution.
>In article <45...@oliveb.olivetti.com>, ch...@Ozona.orc.olivetti.com (David Chase) writes...
>> [only in unsafe code]
In article <39...@shlump.nac.dec.com> nadk...@ashok.dec.com writes:
>Not true as far as I recall. If I remember the report correctly, you CAN decide
>on a type by type basis whether to GC or not. The UNTRACED keyword is provided
>for this purpose. This is true even for SAFE modules. What you might be
>referring to is that untraced REFs can point to traced REFs (or is it the other
>way around ?) only in UNSAFE modules.
Strictly speaking, you are correct. However, the DISPOSE statement is
only allowed in UNSAFE modules. That is, it is "safe" to allocate
non-collectable storage, but unsafe to free it. Lucky you.
You *can* defeat this by suitable trickiness; an UNSAFE module can
export a SAFE interface to the routine
PROCEDURE My_sneaky_dispose(x:ADDRESS) RAISES {} =
BEGIN
DISPOSE(x)
END My_sneaky_dispose;
but you cannot possibly prove this code correct, since there is no way
that it can be guaranteed that this is the last reference to x. Thus,
a programmer has no business whatsoever exporting this procedure in a
SAFE interface. In practice, if you use an UNTRACED REF and which to
ever reclaim that storage (correctly), you'll need to hide it within
an opaque type so that clients cannot make their own private copies of
it. (This is made much easier in the second version of the language.)
Sorry for the digression, but I'm a big fan of truth-in-advertising.
I wouldn't want a bunch of C and C++ hackers to get fired up about
Modula-3 because of this alleged feature only to get pissed off when
they discover that they can't FREE any of that memory that they
allocated. If you're interested in information hiding, garbage
collection, exception handling, threads, and a certain style of
object-orientedness (similar to that in C++, I think), then perhaps
you should check out Modula-3, but don't think that it will solve
*this* problem for you.
David
Larry Campbell
->In article <7...@redsox.bsw.com> camp...@redsox.UUCP (Larry Campbell) writes:
[me] Modula-3, by contrast, allows you to decide on a type-by-type basis whether
[me] objects of the type are to be GC'd or not. This seems to me to be the best
[me] solution.
[chase] To be fair, this is only somewhat the case. In code that is
[chase] explicitly declared as UNSAFE you are allowed to choose on a
[chase] type-by-type basis whether or not objects are GC'd or not. In
[ashok] Not true as far as I recall. If I remember the report correctly, you CAN decide
[ashok] on a type by type basis whether to GC or not. The UNTRACED keyword is provided
[ashok] for this purpose. This is true even for SAFE modules. What you might be
[ashok] referring to is that untraced REFs can point to traced REFs (or is it the other
[ashok] way around ?) only in UNSAFE modules.
You can declare types UNTRACED in both safe and unsafe modules. However,
you can only use DISPOSE in unsafe modules.
In any event, I think my original point still stands - Modula-3 gives you
garbage collection, but doesn't force it on you.
I've redirected followups to comp.lang.modula2, since the C++ folks are
probably losing interest in this thread...