dld@F.GP.CS.CMU.EDU (David Detlefs) (02/11/88)
David Smyth raised some questions he wanted discussed on the net.
I have comments on some of his questions.
1) Exception handling in C++:
I have had a scheme for this described to my by Mike Jones here at
CMU, who has worked with Dr. Stroustrup on a design for a C++
exception handling facility. It seemed to me eminently reasonable;
at the semantic and syntactic level it seemed quite useful, and the
proposed implementation seemed to only impose a performance cost when
the feature was used. The one hitch was that it seemed to require a
native mode compiler. Perhaps Dr. Stroustrup (in his copious free
time) would care to summarize this scheme.
I did have some slight reservations though: I'm familiar with
exceptions only through my use of CLU and Common Lisp. The proposed
mechanism is semantically much closer to the Common Lisp
catch/throw/unwind-protect mechanism than it is to the CLU scheme, in
which you can only signal up to the caller, which must then handle the
exception and resignal if you want it handled somewhere down the call
stack. Thus, an exception in CLU is like an "alternate return," and
the exceptions that a procedure may raise are considered part of its
type signature. This seemed to me to offer more security than the
Common Lisp (or setjmp) approach. I realize that if a CLU-like scheme
were to be adopted for C++ it would in some sense violate the spirit
of the language, in that it would be denying the user access to
functionality that could easily be available, but I think the issue
should at least be thought about.
2) Nothing to say. (Amazing on the net, eh?)
3) Pencil cup example.
The idea is that you have a container class, call it a "pencil
cup," which can contain a set of basically anything, but which has a
"total_weight" function, which adds up the weights of its members,
found by invoking "weight" functions on them. Smythe correctly points
out that multiple inheritance is one way of solving this problem: make
a "weighted_object" class, and have the pencil cup contain them. I
would just like to make sure that type parameterization comes up in
this discussion. My experience with CLU, which supports the
equivalent of classes parameterized over the type of the objects they
contain, is that this is a very useful technique, able to solve the
majority of problems like this that come up in real applications. (How
often do you *really* need a set of things that are related only by
the fact that they have weight?) A failing of CLU (that I hope any
eventual type parameterization mechanism for C++ corrects) is that it
did not allow a class to be parameterized over a procedure type --
only "type" and basic types were valid parameter types. If we are
allowed to parameterize over both element and procedure types, then we
could solve the pencil cup problem by writing set as something like
class set<T: type> {
T* elems;
public:
int sum()<IT: proctype(T) returns (int)> {
for all elems, add up
IT(elem)
end return the sum;
}
Thus, we get not only weight but a possibly a lot of other procedures.
In summary, I just hope we don't forget this kind of parameterization
in this discussion. It's a simple, powerful, and useful technique,
able to solve many of the problems that seem to motivate inheritance
examples.
Davewesommer@athena.mit.edu (William Sommerfeld) (02/14/88)
In article <848@PT.CS.CMU.EDU> dld@F.GP.CS.CMU.EDU (David Detlefs) writes: > I did have some slight reservations though: I'm familiar with >exceptions only through my use of CLU and Common Lisp. The proposed >mechanism is semantically much closer to the Common Lisp >catch/throw/unwind-protect mechanism than it is to the CLU scheme, in >which you can only signal up to the caller, which must then handle the >exception and resignal if you want it handled somewhere down the call >stack. Thus, an exception in CLU is like an "alternate return," and >the exceptions that a procedure may raise are considered part of its >type signature. This seemed to me to offer more security than the >Common Lisp (or setjmp) approach. I realize that if a CLU-like scheme >were to be adopted for C++ it would in some sense violate the spirit >of the language, in that it would be denying the user access to >functionality that could easily be available, but I think the issue >should at least be thought about. Having used CLU for a number of projects for courses here, I would say that the exception handling system is so ``safe'' as to be virtually worthless except as syntactic sugar; it is not significantly different than returning error codes from the routines and checking all the return values (although the implementation can be slightly faster in the general case). If an exception is not handled by the containing procedure, it turns into a failure exception which propagates up the stack. [CLU uses a garbage-collected heap for everything, and has no concept of a ``destructor'' for a type; thus, a lot of cases where you would want to `unwind-protect' to free up storage that is locally allocated just disappear; however, the presence of garbage collection imposes some nasty performance penalties, especially in a virtual memory environment] There is no way in CLU to write a shell which, when some sort of failure is detected, unwinds back to the shell prompt cleanly without putting handling code at every intermediate level. By the way, there is a distinct difference between the ``setjmp'' approach and the LISP approach: with setjmp, you _can't_ do an `unwind-protect' around an arbitrary block of code unless you use some sort of convention for dealing with the setjumps and longjumps. - Bill "Syntactic sugar causes cancer of the semicolon" -- Alan Perlis