Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!zephyr.ens.tek.com!tekcrl!brucec From: brucec@phoebus.phoebus.labs.tek.com (Bruce Cohen;;50-662;LP=A;) Newsgroups: comp.object Subject: Re: prototypes and degenerate cases Message-ID: Date: 14 Sep 90 18:14:02 GMT References: <1990Sep13.235832.23454@Neon.Stanford.EDU> <1608@seti.inria.fr> Sender: news@tekcrl.LABS.TEK.COM Organization: Tektronix Inc. Lines: 28 In-reply-to: jml@wally.altair.fr's message of 14 Sep 90 09:36:03 GMT In article <1608@seti.inria.fr> jml@wally.altair.fr (Jean Marie Larcheveque) writes: > > In article <1990Sep13.235832.23454@Neon.Stanford.EDU> craig@Neon.Stanford.EDU (Craig D. Chambers) writes: >> > The same scheme could be implemented for example in C++, > with something like > > class ellipse { > concrete_ellipse state_holder; > // ... > } > with concrete_ellipse a subclass of ellipse and a > superclass of circle. > But then don't you have to add a set of delegation functions to ellipse so an instance of it can pass on calls to it's instance of concrete_ellipse? Also (a nit), I think that state_holder has to be a pointer to concrete_ellipse, because, concrete_ellipse being subclass of ellipse, there's no way to forward-reference its type for the layout of the structure to be determined. -- --------------------------------------------------------------------------- NOTE: USE THIS ADDRESS TO REPLY, REPLY-TO IN HEADER MAY BE BROKEN! Bruce Cohen, Computer Research Lab email: brucec@tekcrl.labs.tek.com Tektronix Laboratories, Tektronix, Inc. phone: (503)627-5241 M/S 50-662, P.O. Box 500, Beaverton, OR 97077