jima@hplsla.HP.COM (Jim Adcock) (06/20/89)
Now that C++ [almost] has multiple inheritence under the belt, what can we expect to see in the way of parameterized classes? How serious are the intentions to get this into the language? Has any more progress been made in choice of capabilities/syntax? (A better knowledge of where this is going would at least allow us to write hack-parameterized classes more easily converted to the eventual syntax) [signed: sick-of-hack-cpp-parameterization]
baud@eedsp.gatech.edu (Kurt Baudendistel) (06/20/89)
In article <6590158@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: >Now that C++ [almost] has multiple inheritence under the belt, what can >we expect to see in the way of parameterized classes? ... I am fond of the g++ (gnu c++) prototyping capabilities. This system is a separate preprocessor that provides protyping facilities that (supposedly) may eventually grow into a real part of the compiler when such a facility is standardized. Maybe one of its authors will expound on its capabilities for us (Michael?)? -- Kurt Baudendistel --- GRA Georgia Tech, School of Electrical Engineering, Atlanta, GA 30332 uucp: ...!{allegra,hplabs,ulysses}!gatech!gt-eedsp!baud internet: baud%gt-eedsp@gatech.edu
bs@alice.UUCP (Bjarne Stroustrup) (06/20/89)
Jim Adcock at HP Lake Stevens, WA writes: > Now that C++ [almost] has multiple inheritence under the belt, > what can we expect to see in the way of parameterized classes? See `Parameterized Types for C++' in the Proceedings of the Denver USENIX C++ conference and in the first JOOP issue this year. It is quite detailed. > How serious are the intentions to get this into the language? Very. It is not an issue of `if' but of `when'. However, don't hold your breath. These things take time - often more than you would think. > Has any more progress been > made in choice of capabilities/syntax? (A better knowledge of where this > is going would at least allow us to write hack-parameterized classes more > easily converted to the eventual syntax) > [signed: sick-of-hack-cpp-parameterization] I'll second that one.
shankar@hpclscu.HP.COM (Shankar Unni) (06/21/89)
> [signed: sick-of-hack-cpp-parameterization]
Hear, hear..
--
Shankar.grunwald@flute.cs.uiuc.edu (Dirk Grunwald) (06/21/89)
Along the same lines of parameterized types, is ``delegation by pointer'' ever going to be sanctioned? Not having this is, in my book a big loss for C++. It leads to needless duplication of classes and ambigious interface bindings. If you need examples of why this is useful, I can provide them. In each case, you are able to provide an equiv. interface by introducing new classes (if I grok the MI rules), but it's gratitous introduction of classes. -- Dirk Grunwald -- Univ. of Illinois (grunwald@flute.cs.uiuc.edu)
bs@alice.UUCP (Bjarne Stroustrup) (06/23/89)
Dirk Grunwald @ University of Illinois, Urbana-Champaign writes: > Along the same lines of parameterized types, is ``delegation by pointer'' > ever going to be sanctioned? Not soon, maybe never. > Not having this is, in my book a big loss for C++. It leads to needless > duplication of classes and ambigious interface bindings. I really like the concept and see many good uses for it. I implemented it and I and several of my friends tried it out. To my surprise, we all got ourselves into serious messes using it. This led to the observation that `delegation is the goto of data structures.' Naturally, this may not have been a fault of the delegation concept as such but a flaw in my design for C++ (see `Multiple Inheritance for C++' Proc EUUG comference, May'87, Helsinki). I suspect the latter, but since I don't know exactly what went wrong I will need much time to experiment before putting delegation into the language. > If you need examples of why this is useful, I can provide them. > In each case, you are able to provide an equiv. interface by introducing > new classes (if I grok the MI rules), but it's gratitous introduction > of classes. It is better to have `gratuitous classes' than flawed or gratuitous language features.
grunwald@flute.cs.uiuc.edu (Dirk Grunwald) (06/24/89)
Several people asked me to define ``delegation by pointer.'' The meaning I use is that published in the paper ``Multiple Inherietence for C++'' by Stroustrup in section 8 ``Delegation through a Pointer''. This allows you to specify inheritence of interface without having to specify inheritence of instance. For example, consider class Bar, with subclass FooBar, DryBar, WetBar. Now, consider class Gnu, with subclass Gnat and Gnome. We would like Gnat and Gnome to be subclasses of *any kind* of Bar; we care not whether it be a FooBar, DryBar or WetBar. You can do this under C++ MI by declaring: class GnatBar : Gnu, Bar class GnomeBar : Gnu, Bar but, let us conjecture that Bar is really an abstract class, represinting an interface, not an instance. Then, to get an actual *instance* we have to define: class GnatFooBar : Gnu, FooBar class GnatDryBar : Gnu, DryBar class GnatWetBar : Gnu, DryBar But that's not good; want to treat this set of classes as similar things, so we can pass them around & have people treat them as the union of a Bar and a Gnu....So, we use... class GnatBar: Gnu, Bar class GnatFooBar : Gnu, virtual FooBar ...etc... So, now, at the expense of introducing three class definitions, we can finally do what we want. Delegation by pointer says that we can declare a class via: class FooBar : Foo, Bar *p Now, all interface accesses through a FooBar are delegated to a Bar object via the pointer ``p''. You can restrict the semantics slightly and force ``p'' to be bound at instance creation time, or you can allow ``p'' to be changed on the fly. In this case, you only need to introduce a *single* class to do this; you can effect the same results using the ``virtual'' class mechanism, but it's clumsy, at best, and introduces many bogus classes & class definitions. What are my realistic examples? Consider a thread library, were Bar represents the abstract class of ``things that order threads for execution'' and Foo represents the set of ``things that need threads to be ordered,'' e.g., Semaphores, Facilities, ReadyLists, whatever. Either you create a panoply of subclasses, e.g., PrioritySemaphore, FifoSemaphore, LifoSemaphore, PriorityFacility, FifoFacility, LifeFacility, etc or, with delegation, you allow the user to bind instances of ThreadContainers to instances of ThreadSchedulers. -- Dirk Grunwald -- Univ. of Illinois (grunwald@flute.cs.uiuc.edu)