From 5622722273150119217 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,fb1a92fa405c930c X-Google-Attributes: gidf78e5,public From: jpotter@falcon.lhup.edu (John Potter) Subject: Re: nested functions Date: 1999/06/17 Message-ID: <8EU93.18136$uk.261923@newscene.newscene.com>#1/1 X-Deja-AN: 490588655 Approved: Fergus Henderson References: <7jd4c5$nup$1@nnrp1.deja.com> <7jjjr6$r02$1@nnrp1.deja.com> <7jma5c$i85@abyss.West.Sun.COM> <7jmdcv$a56$1@engnews1.eng.sun.com> <7jp9ff$glj@abyss.West.Sun.COM> <7k6063$r86$1@nnrp1.deja.com> <3mP93.15224$uk.221592@newscene.newscene.com> <7k8lot$pts$1@nnrp1.deja.com> X-Original-Date: 16 Jun 1999 16:27:06 -0500 X-Authentication-Warning: backdraft.briar.org: smap set sender to using -f X-Complaints-To: news@news.unimelb.edu.au X-Trace: izvestia.its.unimelb.edu.au 929607473 21876 128.250.29.16 (17 Jun 1999 08:17:53 GMT) Organization: Newscene Public Access Usenet News Service (http://www.newscene.com/) X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUAN2ivDuEDnX0m9pzZAQFuRgGAjXIZ+z2Qg+fKrHCKpOXKVZPkcRbhpvRo qKhxWQcPnPtO2kHcWZWFIuXlp4u0FCUc =oSpg NNTP-Posting-Date: 17 Jun 1999 08:17:53 GMT Newsgroups: comp.std.c++ James.Kanze@dresdner-bank.com wrote: : In article <3mP93.15224$uk.221592@newscene.newscene.com>, : jpotter@falcon.lhup.edu (John Potter) wrote: : > I can write off that complexity as a standard idiom. Of course the : > real increase in length and complexity comes when the context to be : > transfered is non-trivial. Templates can help with that. : You missed the point. The function integrate is used in many different : locations; the additional parameter is of varying types, etc. Of : course, I could make integrate a template function, but if the code is : anything but trivial, this leads to unreasonable code bloat. The function integrate accepts only one type of function pointer. I doubt that there would be many types of additional parameter. In fact, a double** would likely cover almost all cases. That would add one line to the outer function to declare and initialize the C array of double* and add some ugly [] and * to the inner function. Adding arrays of references to the language would solve that problem. :) : And of course, for all I know, integrate could be in a third party : library, to which I don't have the sources. (IMHO, in such cases, in : C++, a functor should be used. In C, an additional void* parameter : should be provided, precisely for passing such context. Yes, that's what I meant by standard idiom. : But in : practice, at least in the few libraries I've seen, this has not been the : case.) That statement excludes the standard library, I assume, from the earlier use of third party. "My great libraries are broken, let's fix the language." I'm not sure that you said that, but I was able to read that. : > I also agree that the functor idiom is an alternative for C++. I : > don't see the need for the extension you presented. It is convient : > to use it locally, but I can manage with it global. : > : > All of these alternatives become much more difficult when the nesting : > level increases. That could be a good thing and maybe the best : > argument against nested functions. : I totally agree that it is a feature which can be misused. I've seen : what people are doing with inner classes in Java -- it's like the early : days of operator overloading in C++, before the word got out that : operator overloading was only good if the overloaded operators did : something similar to what the built-in operator did. : But since when is the argument that something can be misused been a : valid argument for C++? Never. There are; however, examples of making it hard to misuse. Functions return rvalues which may only be bound to const&. We know how to bypass that but it requires action not accident. I seem to remember other examples in D&E where decisions were made that the added feature could be done otherwise and adding it to the language would encourage poor practice. I agree that this argument is only a very small piece of the picture with little weight. But, not invalid. I give it more weight than returning a pointer to the nested function from the enclosing function. Maybe callback with context is a pattern and all patterns are produced to compensate for a missing language feature. To date, that is the only argument that I have seen in this thread. The original poster even complained about a few lines needed to use Borland's closure. I'm satisfied with the idiom/pattern; however, there may yet be something said on the formal closure to enlighten me. John --- [ 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 ]