From 1947471353073116823 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,fb1a92fa405c930c X-Google-Attributes: gidf78e5,public From: Jerry Leichter Subject: Re: nested functions Date: 1999/06/09 Message-ID: <375EDC31.3B7D@smarts.com>#1/1 X-Deja-AN: 487676952 Content-Transfer-Encoding: 7bit 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> X-Original-Date: Wed, 09 Jun 1999 17:27:13 -0400 Content-Type: text/plain; charset=us-ascii X-Complaints-To: news@news.unimelb.edu.au X-Trace: izvestia.its.unimelb.edu.au 928967441 7069 128.250.29.17 (9 Jun 1999 22:30:41 GMT) Organization: System Management ARTS X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUAN17q9OEDnX0m9pzZAQEx/wGAjnSmPcQ8Ii/dY8YiRpJBjqSYyuOob8z/ eJAM3FWqQVd+6sWtdSnpzVwmZWryt7Ml =5iG2 Mime-Version: 1.0 NNTP-Posting-Date: 9 Jun 1999 22:30:41 GMT Newsgroups: comp.std.c++ | >Why do local functions have to have the same calling sequence as | >non-local functions? Given the C++ requirement for all functions to | >be declared prior to a call, the compiler can always tell if a call | >is to a namespace scope funcion or to a local one. | | Consider function pointers: | | [Function pointer fp set to either a local or a global function] | | If the calling sequences for g1::h and f are not the same, | the code can't work. Either you need a different kind of | function pointer for local functions, or you extend the | calling sequence of global functions to match that of local | functions. ... or you use trampolines: When you call a local function through a pointer, you're really calling a small bit of code dynamically generated code that sets up the environment and calls the real function. This adds a cost to calls to local functions through pointers, but has no effect on any existing code, or on code that calls local functions directly. I believe GCC uses this technique. BTW, Modula-3 takes an interesting half-way approach: It has local procedures, but their addresses can only be passed as arguments, not assigned (which I think implicitly prevents them from being returned as the value of a function; one way or another, this isn't allowed). This lets you use local procedures to access local state, but does *not* allow you to create closures - so the implementation can still use purely stack-implemented procedure frames (and could even put trampolines on the stack on machines that let you run from the stack). Local procedures subject to this constraint would be a significantly less intrusive C++ extension. They are much less powerful, of course, but then again you *do* have a reasonable alternative (an object) for most uses of true closures. -- Jerry --- [ 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 ]