From 9009071565127305656 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,4453ceff0a5ed7f7,start X-Google-Attributes: gidf78e5,public From: Richard See Subject: Re: Closures again :) (long) Date: 1997/08/28 Message-ID: <3405AB62.1C08@vega.co.uk>#1/1 X-Deja-AN: 268795760 References: <34046A78.DD58DA46@no.spam.farallon.com> X-Original-Date: Thu, 28 Aug 1997 17:46:26 +0100 Reply-To: Richard.See@vega.co.uk Originator: austern@isolde.mti.sgi.com Organization: Vega Group plc. X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBVAwUBNAXJAUy4NqrwXLNJAQH1EgH+Pu1hPv8oiWuwTH0nLDa6Atixlab/F7qn fmQYCDDYHjZ8Pu2OUQ9E6fIbYC16aW/9oyiDnXDXcZb4wOl5KPeCeg== =F5Hx Newsgroups: comp.std.c++ Don Griffin wrote: > > I have implemented one of the suggested techniques to emulate the > concept of a closure, and I have some questions for anyone familiar with > the topic. > > My code: ... > I see two scenarios for using these for events: > > #1 - Dynamically allocate the closure and keep a pointer to it in the > object that wants to fire the event. > > #2 - Declare the closure as a member of the object with the event > handler. > > > My problems with this approach are: > > 1. Both #1 and #2 have a lot of overhead. I didn't think that #2 had much overhead. #1 had an extra new/delete of an object, that might not be too bad either, depending on your application. There is opportunity to use an optimised memory allocation, since the closures will tend to be the same size. > 2. Since the size and behavior is dynamic, I must deal with > TFunctor*'s and not a closure instance. You could have wrapped them in a reference counting interface. > 3. There is a lot of syntax to setup the closure. It didn't look too bad to me in case #1. > 4. There are lots of templates involved. Two for 0-arguments (1 for > 0-args and void return, and 1 for 0-args w/non-void return), two for > 1-arg, etc.. By the time you get setup for 0-3 arguments you have 8 > templates. There are, but you could always stick to one argument, and pass a struct if you want to pass more than one item of data. > 5. I made the dtor virtual because the closure objects get deleted thru > the base class pointer. In case #1 they do. What % performance hit will making the dtor virtual have on your system? I imagine it would be small compared to the memory management overhead. > Are there any improvements that someone could suggest? Add reference counting to make the interface simpler. > If this is the best that the language can do, I want to re-assert my > strong preference > for a closure in the language. I realize it's too late for me to get > it, but this set of templates is too cumbersome and pricey to be used > for events. It seems to me that most of the price is inevitable, and getting the compiler to implement the workings instead of a library writer wouldn't make it go away. Neither do I find it too cumbersome. How about specifying the interface you would want to be able to use the closures? Then it would be possible to see how close we can get currently, and how much overhead the compiler would be able to remove. --- [ comp.std.c++ is moderated. To submit articles: Try just posting with your newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html Comments? mailto:std-c++-request@ncar.ucar.edu ]