Boost logo

Boost :

From: Max Motovilov (max_at_[hidden])
Date: 2004-03-03 19:58:34


"Darren Cook" <darren_at_[hidden]> wrote in message
news:404668C7.8010501_at_dcook.org...

> I think local names visible inside the anonymous function is the expected
> behaviour.
>
> Can you say more about the potential problems (or point me to a
> paper/discussion if this is well-discussed somewhere else)?

Let's say the inner (anonymous, in this case) function makes recursive
calls. Direct recursion may be disallowed for an anonymous function but,
since a pointer to it exists somewhere, I don't see a way to prohibit
indirect recursion - other than by fiat (i.e. saying that effects of such
shall be undefined). Now you have this function creating multiple frames on
the stack with its own variables AND accessing the stack frame of its
containing function - this, at the very least, means that a pointer to such
frame has to be passed in the call to inner function. In the discussed case,
the inner function is not called by the containing function directly but by
some other code which has no idea whether the pointer passed to it refers to
a regular or an anonymous function, hence a complication of the call
protocol for everybody. Or, "anonymity/locality" becomes a modifier akin to
const and volatile and anonymous functions are no longer usable by
non-template code expecting a function pointer (though this may be an
acceptable compromise).

Come to think of it, local function does not even have to be recursive to
cause this problem - since a pointer to it has been passed through
[multiple] other functions before dereferencing and call, it (local
function) has no way of finding the containing function's stack frame unless
it has been passed an explicit pointer to it. [I re-read this paragraph and
wished for _1, _2 to complement "it" in English]

Hmm.... we can also think of what will happen with nested anonymous
functions :-)

...Max...


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk