shirley@m.cs.uiuc.edu (09/01/88)
I have a simple question that may or may not have a simple answer. If I
want to write code for a certain data structure, say a linked list, and
I want to use it for all classes, can C++ handle this gracefully?
For example, suppose I define a base class "thing", and classes "list" and
"list_node" (probably subclasses of "thing") that define the linked list
ADT for things. Each list node contains a pointer to thing. Now I define
a subclass of thing "integer" that has an access function "void set_value()".
I want code that is the equiv. of
list int_list;
integer i, j;
i.set_value(7);
int_list.add(i);
j = int_list.first();
j.print();
I want to be able to do this using the 'thing-list', and I want to use
it on all sorts of very different subclasses of thing. How about it?
Sorry if this is too simple a question. I am new to C++ and my only
other language is vax-assembler.
THANKS!
Peter Shirley
University of Illinois at Urbana-Champaign
UUCP: {pur-ee,convex,inhp4}!uiucdcs!shirley
ARPA: shirley@cs.uiuc.edu
CSNET: shirley%uiuc@csnet-relaydld@f.gp.cs.cmu.edu (David Detlefs) (09/03/88)
I believe that the best thing to do is to use the C preprocessor to get the effect of paramterized classes, as on page 210 of Stroustrup's book. I'm working on a library of such classes. I think that people sometimes are a little overzealous in trying to make inheritance the answer to all program structuring problems -- the kind of of problem you pose is most simply solved as a parameterized class. (Why require that the list elements be subclasses of "thing"? When you write "list", you want to be able to make lists of anything. When you write a class "foo," you definitely don't want to worry then about whether it should inherit from "linked_list_elem", "tree_elem", "sortable_elem", "hashable", etc. You simply want the compiler to ensure that those things that you do use as parameters to parameterized types have the proper signatures. -- Dave Detlefs Any correlation between my employer's opinion Carnegie-Mellon CS and my own is statistical rather than causal, dld@cs.cmu.edu except in those cases where I have helped to form my employer's opinion. (Null disclaimer.)
morrison@eecs.nwu.edu (Vance Morrison) (09/03/88)
Hello In general I have found the following rule to hold Reuse of the most basic data structures requires the most advanced features of a programming language. That is reuse of a specialized piece of code is easy, but reuse of a generalized 'list', 'array', 'set' is more difficult. In your example of a linked list, yes you can do what you said, but you will find that most (if not all) of the functions must be defined in the derived class. For example list.add(elem) list.setval(elem) list.getval() list.delete() with perhaps the exception of the delete function, all of these functions need to know how something about the type of 'elem' because of this they have to be in the derived class. This problem is characteristic of 'container classes', like arrays, list, sets, trees (essentially the most important data types). There is a solution to this problem, and it lies in the fact that most if not all the information the container class needs to know about its elements is compile time information. Thus with a little extra help from the compilier a generic list can ask for the compilier the infomation it needs. I am in the process of developing a simple preprocessor to C++ that will do this. At present, however, with standard C++, I do not believe there is a truely satisfactory solution to the problem of container classes. Vance Morrison Northwestern Univ
tel@computing-maths.cardiff.ac.uk (Ted Lawson) (09/07/88)
In article <4800034@m.cs.uiuc.edu>, shirley@m.cs.uiuc.edu writes: > ... > I want to write code for a certain data structure, say a linked list, and > I want to use it for all classes, can C++ handle this gracefully? > I know this s not a answer to your question but... An OO language which addresses the problem directly and rather elegantly is Eiffel. In fact Eiffel comes with a library of classes which includes not just lists (of various kinds) but also stacks, trees, queues, deques and other aggregate structures. The type of the object to be stored is defined as a parameter. You can create your own type-parameterised classes or make specialised and combined versions of the library ones using single and multiple inheritance. These classes have most of the properties of other Eiffel classes so you can supply one of them as the actual type-parameter of another. It is then possible to construct interesting composites such as lists of stacks of queues of ... of integers (or whatever). I think the solution is probably neater than anything you achieve with C++. I have yet to compare Eiffel with C++ on performance though. More information... B. Meyer, "Genericity versus Inheritance ", OOPSLA '86 Proceedings, 391-405, (1986) "Eiffel: A Language and Environment for Software Engineering ", Interactive Software Engineering, Inc., Goleta, CA ...oooOOOooo... Not necessarily my employer's views. Ted Lawson
ech@poseidon.UUCP (Edward C Horvath) (09/14/88)
B.Meyer just published (8/88) a comprehensive book on Object-oriented programming; the exact title escapes me (it's at home) but the book is in the Prentice-Hall series Tony Hoare edits. I've only read the first few chapters -- mostly O-O motivation for the traditional programmer so far. Very readable, very cogent. Much more about Eiffel is promised by the Table of Contents. =Ned Horvath=
daven@hpqtdla.HP.COM (David Newton) (09/15/88)
> / hpqtdla:comp.lang.c++ / ech@poseidon.UUCP (Edward C Horvath) / 7:25 pm Sep 13, 1988 / > B.Meyer just published (8/88) a comprehensive book on Object-oriented > programming; the exact title escapes me (it's at home) but the book is in > the Prentice-Hall series Tony Hoare edits. I've only read the first few > chapters -- mostly O-O motivation for the traditional programmer so far. > Very readable, very cogent. Much more about Eiffel is promised by the > Table of Contents. > > =Ned Horvath= > ---------- > Further details of the book are: Object-oriented Software Construction Meyer Prentice Hall ISBN 0-13-629031-0 It is a thorough, reasoned book, well worth reading. David Newton hplabs!hpqtdla!daven
tel@computing-maths.cardiff.ac.uk (Ted Lawson) (09/17/88)
In article <502@poseidon.UUCP>, ech@poseidon.UUCP (Edward C Horvath) writes: > B.Meyer just published (8/88) a comprehensive book on Object-oriented > programming; Yes the book is "Object-Oriented Software Construction", Prentice Hall ISBN 0-13-629031-0. Quite a refreshing look at OO and probably a good introduction to the subject since the confusing method/message terminology spawned by the Smalltalk community is missing. Instead Meyer talks in terms of procedures and functions providing a convenient little stepping stone into OO for those who are long steeped in conventional development methods. Most of the examples are in Eiffel of course though there is a short review of other languages which includes hints on how to construct object-oriented software if all you've got is Fortran...hmmm. Big (533 pages) and well written though there's more than one typo and some of the illustrations suggest that his mouse needs oiling. Re: Eiffel, we installed it last January but nobody here's found the time to take it for a good long walk yet. Has anyone else had a go? And is there a chance that whoever or whatever it is up there that sets up news groups who could instigate a comp.lang.Eiffel for us ? Pal for life. (my views etc.) Ted Lawson "The lost object is always in the last place you look."