Subject: Re: [boost] [local_function] any interest in a LocalFunction library?
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2010-09-17 09:48:48
On Thu, Sep 16, 2010 at 6:32 PM, Pierre Morcello
> Hi Lorenzo,
>> Lorenzo Caminiti wrote :
>> I have decided to provide a single block macro
>> which allows to bind both const and non const so the users
>> can decide
>> which bound variables need to be cons within the block and
>> which do
>> not. If you want a pure const-block then you'll simply bind
>> variable as `const&`. Blocks of course execute in-place
>> right where
>> they are defined. I have also kept the block break feature
>> via the
>> macro `BOOST_LOCAL_BLOCK_BREAK` (you get a compiler error
>> if you just
>> try to use `return`).
> I would have prefered to see the FUNCTION + 'return' personnally.
> But, I think I get your point : local unnamed macro function can be generated easily from your local named function. I made some tests to check and this seems ok for me, as long as several local classes can share the same name in a function.
> Here is an example of what I mean :
> void TestDoubleLocalFunc::aFunction(void)
> class unnamed
> int that;
> } something;
> something.that = 1;
> class unnamed
> std::string those;
> } something;
> something.those = "";
> This use 2 local classes with the same name. It did compile under VS2008, however is it tolerated in C++ standard ?
> If not, I would prefer that you provide an unnamed local function macro which does not require the user to write once more the name of the function in LOCAL_FUNCTION_END(nameOfTheFunction). This is doable (see the first code I sent you), and would allow to write the name of the function only once, and not require it several times as in your actual LOCAL_FUNCTION macros.
Yes, I understand your suggestion on unnamed local functions and I did
not mean to give the impression that I decided not to follow it. The
examples I have posted so far only reflect the design decisions I
indicated in the "CURRENT STATUS" section of my previous email. The
> OPEN ISSUES
> a) I am not sure if local functions can be nested into one another. In
> other words, I do not yet know if it will be possible to define a
> local function from within another local function.
> b) I am not sure if I will provide unnamed local functions (void or
> not) and if so what their syntax will look like. It seems if you need
> this you can just use the local functions macros to program it without
> a dedicated syntax (but still discussing...).
> c) I am not sure if I will provide local functions that execute
> immediately after they are defined. This might relate to b). Again, if
> you need this you can simply call the local function right after you
> define it without a dedicated syntax (but still discussing...).
are still open. As you can see, b) is unnamed local function so I will
consider your suggestions (as well as other's) in detail. Ultimately,
I will indicate the rational of my/our design decisions as well as
other design options we discussed in the documentation so reviewers of
the library will be able to see the alternatives and eventually
request a changes.
Note that, from an implementation prospective, unnamed local functions
(with return type or void), LOCAL_BLOCK, LOCAL_EXIT, etc are trivial
corollaries of the LOCAL_FUNCTION macros so my current focus really is
on finalizing a solid LOCAL_FUNCTION design/implementation.
Finally, thanks a lot to everyone for you comments to my last emails.
I will take the time to look in details to your arguments and reply
(possibly with actual working code examples).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk