Re: [boost] [local_function] any interest in a LocalFunction library?

Subject: Re: [boost] [local_function] any interest in a LocalFunction library?
From: Pierre Morcello (pmorcell-cppfrance_at_[hidden])
Date: 2010-09-13 17:33:59

>><lorcaminiti_at_[hidden]> wrote:
>>
>> Hello all,
>>
>> Local functions are essentially implemented as member functions of
>> local classes. These member functions do not have to be static and
>> they could be virtual allowing for a local function to override one
>> another.
>>
>> However, I cannot understand if this overriding "feature" has any
>> value at all... Have you ever used anything similar? Can you think of
>> a use case for it?

I can't think of any.

>> this or this_ ?

I personnaly prefer this_ since it is a minor problem, and seems safer.

>> bound or bind?

I am ok with bound, or bind as long as there is no compatibility problems with boost::bind. It would be necessary to explain in the documentation that it is not the 'bind' of boost bind. 'closure' feels a bit long, while 'ref' would even sound better to my humble ears... but this is nothing fundamental to me neither.

>> Lorenzo wrote :
>> This functionality plus the one of Boost.Breakable-like
>> breakability would be provided by Boost.Block in terms of both const
>> and non-const blocks.
>> I implemented Boost.Block using Boost.LocalFunction. Note that from
>> within a Boost.Block, return jumps to the end of the block (and it
>> does not exit the enclosing function) therefore also proving the
>> Boost.Breakable functionality discussed in
>> http://archives.free.net.ph/message/20090906.123719.b890ff7a.el.html.
>> However, I am not sure if this "block breakability" via return is a
>> feature or a limitation because users could expect `return;` to quit
>> exit the enclosing function as usual and not just the local
>> void-function used to implement the Boost.Block

I am myself not convinced by your propositions on this point. If you present it like a 'block', when it's a local fuction directly called, then its more confusing than necessary.

Concerning boost.breakable it was a very simple one liner, which happens to be useful in some cases.

Concerning my earlier suggestion to add to your library was simply a local function called in-place (so presented as a local function). Of course, if you name it 'block' it is confusing. But if you use the term 'function' then it is ok for everyone to use 'return' and have a much easier interface.

instead of :

CONTRACT_DETAIL_BLOCK( (this)(x) )
{
if (x <= 0) CONTRACT_DETAIL_BLOCK_BREAK; // `return` jumps to block's end.
this_->x_ = x; // OK, `f` (so `this`) is non-const member function.
} CONTRACT_DETAIL_BLOCK_END

using something like :

UNNAMED_FUNCTION( (this)(x) )
{
if (x <= 0) return;
this_->x_ = x; // OK, `f` (so `this`) is non-const member function.
} UNNAMED_FUNCTION_END

would be clearer in my humble opinion. You could replace UNNAMED_FUNCTION by DIRECT_FUNCTION or something else which clearly shows that it is a function. By the way, this was the interface used by the implementation I send you at the beginning (NESTED_FUNCTION + return) .

Concerning the 'default' values that you proposed, it is an interesting idea, though I am not sure I would have a use for it.

I consider you are doing a clean and serious work, keep on!

Best regards,

Pierre Morcello