From 3461663450694909802 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,a69618ea97f65037 X-Google-Attributes: gidf78e5,public From: Christopher Eltschka Subject: Re: nested functions Date: 1998/04/28 Message-ID: <35459993.3BC581B0@physik.tu-muenchen.de>#1/1 X-Deja-AN: 348365546 Approved: Fergus Henderson Content-Transfer-Encoding: 7bit References: <6hac23$8lb$1@news2.isdnet.net> <353b85b9.0@news.iprolink.ch> X-Original-Date: Tue, 28 Apr 1998 10:55:47 +0200 Content-Type: text/plain; charset=us-ascii Organization: [posted via] Leibniz-Rechenzentrum, Muenchen (Germany) X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUANUWmKOEDnX0m9pzZAQHC4wGAoRU5xf4NEfPCLf5mXZp0zzIaAHUNCKJc IPmEy0Sq8t3bOVHKyIqzq1nmb/gdwzSJ =OYZi Mime-Version: 1.0 Newsgroups: comp.std.c++ Jens Kilian wrote: > > "Didier Trosset-Moreau" writes: > > Bjarne Stroustrup himself has explained that allowing them would generate > > lots of overhead in calls (if you think a little about the call mechanism, > > you'll reach the same problem very early). And decided to accept no overhead > > when designing C++. > > To properly implement nested functions, you must have true closures. I disagree. To properly implement nested functions, you have to implement nested functions. To properly implement closures, you have to implement closures (which indeed includes support for nested functions). > AFAIK, even GCC supports only downward closures. If nested functions > were supported the way they are (and have been for decades) in Lisp, > the following would be legal: > > int (*)(void) make_counter(void) > { > int counter = 0; > int count(void) { return counter++; } > > return count; > } > > void > some_function(void) > { > int (*counter1)(void) = make_counter(); > int (*counter2)(void) = make_counter(); > > // This would output the sequence 0, 0, 1, 1. > cout << counter1() << counter2() << counter1() << counter2(); > } > > I think it's safe to say that C/C++ will *never* support such constructs. Other thanm nested functions, closures would cause problems with the C++ object model. Look for example at the following code: struct X { X() { cout << "X()" << endl; } ~X() { cout << "~X()" << endl; } }; typedef X* (*fun)(); fun f(int i) { X x; X* c1() { return &x; } X* c2() { return 0; } if (i>0) return c1; else return c2; }; Now, when should the destructor of x be called? Normally, it would be called at exit from f, but due to closures x might still be in use (it is, if i>0). Now, if i<=0, c2 is returned which doesn't need x, so x may be destructed at once. However, if c1 is returned, x is still needed. Indeed, it is still needed as long as the function pointer is in use (including all copies). Thus it's very much overhead just to deside when X should be destroyed. Note that you don't have this problem if you just have nested functions, as the pointer to the local function is invalid as soon as f returns (just as any other pointer to local entities). Closures might be useful, but have too complicated interaction with the C++ object model (I guess they would work well with the Java object model). Note however, that once you return from the enclosing function, a closure is in no way different from a function object, from the user's point of view. And before the return, they are not any different to ordinary nested functions. Indeed I guess I would never use them at all. However, I'd still like to see nested functions in C++. While they are not a tool you use everyday, they are very handy in some situations, and they don't cause any problems with the C++ object model. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]