Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!ukc!ox-prg!culhua.comlab!bill From: bill@robots.ox.ac.uk (& Triggs) Newsgroups: comp.lang.c++ Subject: Re: Common data structures Message-ID: Date: 12 Jun 91 13:34:50 GMT References: <1991Jun10.200429.26713@lynx.CS.ORST.EDU> <1991Jun11.061402.21934@lth.se> Sender: news@prg.ox.ac.uk Organization: /users6/bill/.organization Lines: 69 In-reply-to: dag@control.lth.se's message of 11 Jun 91 06:14:02 GMT I would agree with Dag Bruck that any real list package must let objects be members of multiple lists - there are too many toy C++ examples and not enough real implementations about at present! However if you have a parametrised list class, you can always use it to store pointers or references to objects rather than the objects themselves, whereas if you have a 'list-of-pointer' class you can't use it to store real objects. So any decent list package should allow you to store an arbitrary data type in the nodes for flexibility, even though most people will only use it to store pointers. He also mentions the problem that 'list-of-foo' and 'list-of-const-foo' are completely independent types as far as the compiler is concerned. This is a bit of a nuisance, but can be worked around either by (i) deriving a 'list-of-foo' from 'list-of-const-foo' which casts away the constness of the returned foo's, or (ii) providing a list-of-foo -> list-of-const-foo cast operator. (i) is cleaner & reuses code more, but (ii) is likely to be easier to implement if you have a generic list template class, since you don't need to figure out which const-foo -> foo wrappers to build. Do other people share my feeling that C++ is not quite making the grade as far as code reuse goes? - All of the 'solutions' I see seem to be convoluted, bulky, and difficult to use. In particular, too many little 'helper' and 'wrapper' functions seem to be required for hygiene and sanity... Maybe we should all be using sm*llt*lk ::-)) Sorry, I'm probably just dumb and I'll wash my mouth out, but I find smalltalk collections incomprehensible when they're implemented in C++ - ie NIHCL. Too many tangled pages of macros and headers for me! Libg++ is OK I guess, but it would be nicer if you didn't need to include an entire separate list implementation for each type of list you have - a better solution would probably be a really tight & nasty void*-chasing core implementation with a fashionable replicatable C++/template wrapper class to interface with it. The list code would require comparison operations from the wrapper and would provide raw bytes for the wrapper to construct list node data objects into (disgusting!), so we might have to sort out this silly 'constructors are not real functions' business [ARM 12.1 p 265]. An explicit constructor call 'bytes->Foo(...)' or '((Foo*)bytes)->Foo(...)' OUGHT to be a legal construct creating a Foo in the given (void*) bytes, just as an explicit destructor call is legal [ARM 12.4]. Having to overload operator new just to get this behaviour seems silly to say the least. I guess the advantages of this approach are not so clear when you only have lists, but when your application starts needing multiple copies of B+ or splay trees you begin to notice the size difference... -- Bill Triggs Oxford University Computing Laboratory 11 Keble Rd Oxford OX1 3QD U.K. tel +44-865-273157 fax +44-865-273839