Boost logo

Boost :

Subject: Re: [boost] [local_function] any interest in a LocalFunction library?
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2010-09-14 14:25:14

On 14/09/10 03:52, Lorenzo Caminiti wrote:
> I agree, if the macro is named `..._FUNCTION` then `return` is not
> confusing. What is the use case for unnamed local functions? Is it
> just the breakable feature?
> All in all, you can always just define a named local function and call
> if right away with one extra line of code:
> (void) (unamed)( (bound)((this)(&x)) )
> ) {
> if (x <= 0) return;
> this_->x_ = x;
> unamed();
> I am not sure of the utility of unnamed local functions but if there
> is a clear use case for them, they would be really trivial to
> implement. I think what we need to find is a good use case for this.

One thing that occurs to me is the possibly utility of unnamed local
functions which are not void. For example, I sometimes want to have a
variable which has to be non-const for a bit while I initialize it, but
is then const (in principle). It would be nice to allow enforcing this
(somewhat the reverse of BOOST_BLOCK_CONST).

So, code like this:

Foo y;
// y should not be changed hereafter

which can be implemented using the stuff you've already offered as for

(Foo) (unamed)( (bound)((&x)) )
) {
  Foo y;
  return y;
Foo const y = unamed();

but is there value in providing dedicated functionality? e.g. there are
three occurrences of 'Foo' there which might in theory by named only once.

Another closely related issue is when you want to have an object briefly
to pass to the constructor of another but destroy it soon afterwards
(i.e. not have the order of construction be the reverse order of
destruction); local functions could help there too. Right now I might do

boost::scoped_ptr<Bar const> w(new Bar(x));
Foo y(*w);
w.reset(); // Dispose of w soon, e.g. to free resources
// Proceed to use y and never mention w again

whereas with local functions I could do

(Foo) (unamed)( (bound)((&x)) )
) {
  Bar const w(x);
  return Foo(w);
Foo y = unamed();

and again it might be helpful to support this use case directly.

I'm not convinced either of these (alone or together) is indeed worth a
dedicated syntax, but they're other use cases to consider. In
particular, these are cases where the name of the function doesn't
really matter (and would be troublesome to settle on -- I'd probably use
"make_y" or something similarly banal).

John Bytheway

Boost list run by bdawes at, gregod at, cpdaniel at, john at