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? <snip> All in all, you can always just define a named local function and call if right away with one extra line of code:
BOOST_LOCAL_FUNCTION( (void) (unamed)( (bound)((this)(&x)) ) ) { if (x <= 0) return; this_->x_ = x; } BOOST_LOCAL_FUNCTION_END(unamed) 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.setMagic(x); // y should not be changed hereafter which can be implemented using the stuff you've already offered as for example BOOST_LOCAL_FUNCTION( (Foo) (unamed)( (bound)((&x)) ) ) { Foo y; y.setMagic(x); return y; } BOOST_LOCAL_FUNCTION_END(unamed) 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 BOOST_LOCAL_FUNCTION( (Foo) (unamed)( (bound)((&x)) ) ) { Bar const w(x); return Foo(w); } BOOST_LOCAL_FUNCTION_END(unamed) 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