kelley@halley.UUCP (Michael Kelley) (09/24/90)
A couple of questions: Does anyone know of a library of generic data structures (lists, trees, associative arrays, etc.) with a parameterized interface in keeping with the "template" syntax? How about a non-NIHCL version which I could create a template interface for? A colleague of mine mentioned an AT&T package used in-house, but now maybe ready to hit the streets? What's the word from various UNIX vendors on future C++ releases? Specifically, I'm wondering if AT&T will continue to translate C++ to C, or will implement a C++ to assembly compiler? And will Sun continue to port AT&T's work, or are they working on their own implementation? What are your views on an appropriate name for a run-time function to return class information? Linton suggested "dossier", but that sounded a little too government-ish having grown up in Los Alamos. So, I've implemented the "typeof" function. It can be used as both a function taking one argument, or as a virtual member function taking no arguments. It's generated solely from the object files prior to link time--no source code needed. We're using it to cast down to virtually derived classes, do exception handling as specified at the C++ conference, and some other funky things. But, I'm a little concerned about a name-clash with future C++ versions, since it's mentioned as a compile-time operator in the Stroustrup paper presented in Denver. Thoughts? And when can we look forward to exception handling from AT&T? Please post if you have something of general interest, or write to me if you want to talk specifics. Mike Kelley Tandem Computers, Austin, TX halley!kelley@cs.utexas.edu (512) 244-8830 / Fax (512) 244-8247 -- Mike Kelley Tandem Computers, Austin, TX halley!kelley@cs.utexas.edu (512) 244-8830
gbooch@ajpo.sei.cmu.edu (Grady Booch) (09/25/90)
In answer to your question, Mike Vilot and I have developed a library for C++ that uses templates. There are over 400 clases in the library, covering stacks, lists, strings, queues, dequeus, rings, maps, sets, bags, trees, and graphs, and tools for searching, sorting, filtering, pattern matching, and so on. we will be presenting a paper at the upcoming oopsla/ecoop on the design of the components (I believe the presentation ison wednesday morning). egb
cline@cheetah.ece.clarkson.edu (Marshall Cline) (09/25/90)
In article <995@halley.UUCP> kelley@halley.UUCP (Michael Kelley) writes: >A couple of questions: >Does anyone know of a library of generic data structures (lists, trees, >associative arrays, etc.) with a parameterized interface in keeping with the >"template" syntax? I'm sure you're aware of libg++ by Doug Lea (it's had a pseudo-template mechanism for quite a while now). >What are your views on an appropriate name for a run-time function to return >class information? How about `0' :-) Runtime (weak) typing is wonderful if you want a toy language that will solve toy problems. Strong typing is nearly essential for programming in the large. Smalltalk provides runtime typing but does NOT provide any compile time typing. C++ is exactly the opposite, which is the real tragedy of translating Smalltalk-like libraries into C++. Ie: forget the speed hit. Forget the 2x to 3x more new/delete calls caused by the Smalltalk model. Forget the 2x more pointer dereferences, and just think about discarding the only ONLY **ONLY** type checking the language *gives* you. The Smalltalk library was designed for Smalltalk, but not for C++. Not to sound like I'm double minded or anything, but Keith Gorlen's NIHCL does a wonderful job of providing persistent objects. Ideally persistence should be buried in the language so as to avoid the temptation to check the type of an object at runtime for other purposes as well (it may sound trivial, but: you only need to check the type of a referenced object when you don't know the type, and that implies you're relying on weak typing). I wish C++ proper gave us persistence; that way no one would have to pay the horrible prices imposed by Smalltalk-like C++ libraries. >Linton suggested "dossier", but that sounded a little >too government-ish having grown up in Los Alamos. So, I've implemented the >"typeof" function. It can be used as both a function taking one argument, >or as a virtual member function taking no arguments. It's generated >solely from the object files prior to link time--no source code needed. >We're using it to cast down to virtually derived classes... Pointer casting is the goto of OOP. In structured programming, everything revolves around the control flow. Goto's can mess up the control flow, which messes up `everything'. In OOPLs, everything is in the `type' of the objects. Pointer casts can mess up the type, which messes up `everything'. There are a few places where the analogy breaks down (a wrong goto merely passes control down the wrong branch, but a wrong pointer cast can cause an arbitrary member variable to be treated as if it were the vptr! BOOM!). I think you'll find that the template mechanism will give you the kind of flexibility to conveniently support strong typing. You'll never (well... *almost* never) have to do a pointer cast. Marshall Cline -- ============================================================================== Marshall Cline / Asst.Prof / ECE Dept / Clarkson Univ / Potsdam, NY 13676 cline@sun.soe.clarkson.edu / Bitnet:BH0W@CLUTX / uunet!clutx.clarkson.edu!bh0w Voice: 315-268-3868 / Secretary: 315-268-6511 / FAX: 315-268-7600 Career search in progress; ECE faculty; research oriented; will send vita. PS: If your company is interested in on-site C++/OOD training, drop me a line! ==============================================================================
vaughan@mcc.com (Paul Vaughan) (09/25/90)
From: cline@cheetah.ece.clarkson.edu (Marshall Cline)
Runtime (weak) typing is wonderful if you want a toy language that will
solve toy problems. Strong typing is nearly essential for programming in
the large. Smalltalk provides runtime typing but does NOT provide any
compile time typing. C++ is exactly the opposite, which is the real tragedy
of translating Smalltalk-like libraries into C++. Ie: forget the speed hit.
Forget the 2x to 3x more new/delete calls caused by the Smalltalk model.
Forget the 2x more pointer dereferences, and just think about discarding the
only ONLY **ONLY** type checking the language *gives* you. The Smalltalk
library was designed for Smalltalk, but not for C++.
We use elements of NIHCL (actually extracted from the old OOPS) rather
productively in conjunction with the compile time type checking. The
OOPS based stuff supports interactive objects that must be manipulated
by the user, both with user written code loaded at runtime and with
more direct mechanisms. We don't tend to use OOPS based container
objects per se; we use libg++ style lists and queues and other things.
We do typecasts from time to time, mostly of the form
Base* foo;
if(foo.isA(class_MyBase)) {
MyBase* myfoo = (MyBase*) foo;
. . .
}
as a way to keep the program modular, but only at an interactive
level--that is, we don't do dynamic type checking and casting in code
that really needs to run fast.
So, I don't look at it as throwing away the only type checking in the
language. It merely augments the type checking capability. You might
question the integrity of the dynamic type checking, since it's not
built in to the compiler, but I've certainly found more bugs in g++
than I have in this code. The upshot is, you can use Smalltalk-like
concepts (actually, I usually think more about CLOS) productively in
conjunction with C++.
Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639
Box 200195, Austin, TX 78720 | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughankgorlen@sparkler.dcrt.nih.gov (Keith Gorlen) (09/26/90)
In article <CLINE.90Sep25002931@cheetah.ece.clarkson.edu>, cline@cheetah.ece.clarkson.edu (Marshall Cline) writes: |>Runtime (weak) typing is wonderful if you want a toy language that will |>solve toy problems. Strong typing is nearly essential for programming in |>the large. Smalltalk provides runtime typing but does NOT provide any |>compile time typing. C++ is exactly the opposite, which is the real tragedy |>of translating Smalltalk-like libraries into C++. Ie: forget the speed hit. |>Forget the 2x to 3x more new/delete calls caused by the Smalltalk model. |>Forget the 2x more pointer dereferences, and just think about discarding the |>only ONLY **ONLY** type checking the language *gives* you. The Smalltalk |>library was designed for Smalltalk, but not for C++. |> |>Not to sound like I'm double minded or anything, but Keith Gorlen's NIHCL |>does a wonderful job of providing persistent objects. Ideally persistence |>should be buried in the language so as to avoid the temptation to check the |>type of an object at runtime for other purposes as well (it may sound |>trivial, but: you only need to check the type of a referenced object when |>you don't know the type, and that implies you're relying on weak typing). I |>wish C++ proper gave us persistence; that way no one would have to pay the |>horrible prices imposed by Smalltalk-like C++ libraries. |> |>Pointer casting is the goto of OOP. |>In structured programming, everything revolves around the control flow. |>Goto's can mess up the control flow, which messes up `everything'. |> |>In OOPLs, everything is in the `type' of the objects. |>Pointer casts can mess up the type, which messes up `everything'. |> |>I think you'll find that the template mechanism will give you the kind of |>flexibility to conveniently support strong typing. You'll never (well... |>*almost* never) have to do a pointer cast. |> |>Marshall Cline While I'm sympathetic with this statement, I don't think I'd characterize the use of Smalltalk-like libraries with C++ as a "tragedy". As Marshall admits, there are times when you have to do a pointer cast. For example, if you're using a polymorphic container, you will at times need to do a downward cast to the derived type of an object obtained from the container. If you *have* to do such a cast, it's better to have a mechanism for checking that the cast is safe rather than just doing it without protection. I think this issue is more likely to arise for the designer of a highy general, reuseable, library class who can make fewer assumptions about what is safe than for an applications-level programmer. One problem with the Smalltalk approach is that since only general, polymorhic containers are provided, they are used in places where a type-specific container would suffice, thus possibly sacrificing type safety and efficiency. An improvement would be to provide type-parameterized container classes that could handle both polymorhic and type-specific situations, as we discuss briefly in Section 14.3 of our book. A related problem with using the Smalltalk approach in C++ is the tendency to define a base class with a set of virtual member functions that is the union of all the virtual functions implemented by all its derived classes. This is done in an attempt to eliminate the need for downward casts. The problem is that when a derived class can't sensibly implement one of these virtual functions, it implements it to cause a run-time error, which amounts to a subtle way of bypassing C++'s static type checking *without* an explicit downward cast. Using multiple inheritance so that derived classes can be more selective about which inherited virtual functions they are expected to implement may offer some help with this problem. There are some problems with the Smalltalk approach, but I don't think it should be trashed because of them. Rather, I think it's an interesting starting point for making use of new or future C++ features such as multiple inheritance and parameterized types. Keith Gorlen phone: (301) 496-1111 Building 12A, Room 2033 uucp: uunet!nih-csl!kgorlen National Institutes of Health Internet: kgorlen@alw.nih.gov Bethesda, MD 20892
mrs@mx.csun.edu (Mike Stump) (09/26/90)
In article <704@ajpo.sei.cmu.edu> gbooch@ajpo.sei.cmu.edu (PUT YOUR NAME HERE) writes: >In answer to your question, Mike Vilot and I have developed a library for C++ >that uses templates. There are over 400 clases in the library, covering >stacks, lists, strings, queues, dequeus, rings, >maps, sets, bags, trees, and graphs, and tools for searching, sorting, >filtering, pattern matching, and so on. Now all you have to do is to name it, and tell us were to ftp it from! Please... -- If I can get mail to you via a legally registered fully qualified domain name, you could be on Saturn for all I care. -- quote by Bob Sutterfield <bob@MorningStar.Com>
bobatk@microsoft.UUCP (Bob ATKINSON) (09/26/90)
Marshall Cline writes: >In article <995@halley.UUCP> kelley@halley.UUCP (Michael Kelley) writes: >>What are your views on an appropriate name for a run-time function to return >>class information? >Runtime (weak) typing is wonderful if you want a toy language that will >solve toy problems. Strong typing is nearly essential for programming in >the large. Static typing is *orthognal* to being able to query an object to learn about some of the characteristics of its type, which is often done by returning a class-related object. It is a perfectly reasonable thought to consider adding a member fn to C++ objects, say, to return such a CRO. Bob Atkinson Microsoft
gbooch@ajpo.sei.cmu.edu (Grady Booch) (09/26/90)
re the c++ library vilot and I are developing: if any of you aren't going to oopsla and/or won't haveaccess to the proceedings, e-mail me your (physical) address and I'll send you a copy of the paper we are presenting. egb
dan@dyndata.UUCP (Dan Everhart) (10/02/90)
In article <704@ajpo.sei.cmu.edu> gbooch@ajpo.sei.cmu.edu (Grady Booch) writes:
In answer to your question, Mike Vilot and I have developed a library for C++
that uses templates. There are over 400 clases in the library, covering
stacks, lists, strings, queues, dequeus, rings,
maps, sets, bags, trees, and graphs, and tools for searching, sorting,
filtering, pattern matching, and so on.
Sounds neat; are you planning to distribute the library?geoff@circus.camex.com (Geoffrey Knauth) (10/03/90)
>In article <704@ajpo.sei.cmu.edu> gbooch@ajpo.sei.cmu.edu (Grady Booch) writes: > In answer to your question, Mike Vilot and I have developed a library for C++ > ...maps, sets, bags, trees, and graphs, and tools for searching... What's the difference between a set and a bag? Geoffrey S. Knauth geoff@camex.com Camex, Inc., 75 Kneeland St. geoff%camex@uunet.uu.net Boston, MA 02111, (617) 426-3577 x451 --standard disclaimers--
gbooch@ajpo.sei.cmu.edu (Grady Booch) (10/03/90)
In answer to Geoffrey'
s question:
a set is a container than may contain only one instance of any value on the container's domain; a bag may contain more than one instance.
for example, consider a set of integers, versus a bag of integers. a bag might contain the items {1, 1, 1, 3, 7, 7, 9, 50, 100, 100}; a set may not have
duplicate entries.
egbmarc@dumbcat.sf.ca.us (Marco S Hyman) (10/04/90)
In article <1549@camex.COM> geoff@circus.UUCP (Geoffrey Knauth) writes:
What's the difference between a set and a bag?
Every element in a set is unique. Not so in a bag. {1,2,3} can be either
a set or a bag. {1,2,2,3} is only a bag. (At least that's how I was
taught).
// marc
--
// marc@dumbcat.sf.ca.us
// {ames,decwrl,sun}!pacbell!dumbcat!marc