Boost logo

Boost :

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 >> >> 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

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