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

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
<pmorcell-cppfrance_at_[hidden]> wrote:
> Hi Lorenzo,
>
>> Lorenzo Caminiti wrote :
>> I have decided to provide a single block macro
>> `BOOST_LOCAL_BLOCK`
>> 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
>> all
>> 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
>                {
>                public:
>                        int that;
>                } something;
>                something.that = 1;
>
>        }
>        {
>                class unnamed
>                {
>                public:
>                        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:

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

--
Lorenzo