Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!udel!rochester!PT.CS.CMU.EDU!F.GP.CS.CMU.EDU!dld
From: dld@F.GP.CS.CMU.EDU (David Detlefs)
Newsgroups: comp.lang.c++
Subject: Re: Questions for Bjarne
Message-ID: <848@PT.CS.CMU.EDU>
Date: 10 Feb 88 19:32:38 GMT
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 67

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.

Dave