Re: [boost] [local] Simplifying the parenthesized syntax

Subject: Re: [boost] [local] Simplifying the parenthesized syntax
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2011-02-12 13:57:49

On 12/02/11 16:42, Lorenzo Caminiti wrote:
> On Sat, Feb 12, 2011 at 5:50 AM, John Bytheway
>>>        // Member with function name for recursive calls. This cannot be
>>>        // defined sooner because the function name is only available here.
>>>        function_type factorial;
>>
>> Amusingly I think this member could be static too, although it would be
>> rather odd and I'm not claiming it's a good idea.  I'm just wondering
>> whether minimizing sizeof(functor_29) could help optimizers.  I have no
>> particular evidence, and indeed it could make matters worse to have
>> static members.
> 
> It could be static in theory but unfortunately local classes cannot
> have static member variables in C++ :(

I didn't know that.  Crazy limitations, but I guess it makes sense in
retrospect.  I wonder if this limitation is also removed in C++0x?

However, on reflection I realised that it wouldn't work anyway (at least
when there are bound variables) because the function that the contained
the local function would not then be re-entrant.  If it were called
while the functor object was extant then another version of the same
functor would be created and mess with this variable, after which the
outer functor would behave incorrectly when performing a recursive call
(it would e.g. have dangling references to the bound variables).

> This is actually VERY
> unfortunate because if I can make the `factorial` member variable
> static then I can make the `body` function static so programmers
> cannot mistakenly use `this` instead of `this_` in the body code (yhe
> `body` needs to access the `factorial` member functor for recursive
> calls -- see LIMITATION in my code comments below).

A shame, yes, but I wouldn't go so far as to say VERY unfortunate :).

>> Yes, in C++0x local structs can be passed as template parameters.
>> Obviously, in C++0x there are lambdas too, so you might think your
>> library is useless, but I'd expect most compilers to support passing
>> local structs as template parameters before they support lambdas, so
>> there is some advantage in having this intermediate implementation.
>> Also, your macros would allow writing code that worked in C++0x and
>> C++03, with the virtual function business in only those compilers/modes
>> where it is necessary.
> 
> OK, I understand. Yes, the code should be optimized for C++0x/C++03
> (it should be easy to do). I'll work on these compiler-specific
> optimizations if the library gets accepted.

Well, at the rate reviews go lambdas might be in place in most compilers
by the time you library is accepted :(.  But let's hope it goes faster
than that :).

John