Re: [boost] Giving names to formal parameters of lambda expressions: a named placeholder trick.

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-04-02 16:18:21

On Wed, Apr 2, 2008 at 7:16 PM, Eric Niebler <eric_at_[hidden]> wrote:
> Giovanni Piero Deretta wrote:
>  >
>  > Anyways, I see that you take great care to guarantee static
>  > initialization of stateful function objects. Do you really think this
>  > is a case that is worth supporting? What are the use cases? (for
>  > example, did you use this functionality when implementing oven?).
>  >
>  > It seems to me that it complicates a lot the interface of the library
>  > (with tons of ugly macros). I understand that this functionality is
>  > opt-in (i.e. it is there only if you want it), but I feel
>  > unconfortable. May be I'm worring too much, but I think that it really
>  > makes the docs hard to follow.
>
>  The ability to statically initialize global objects is pretty important.
>  In the early days of xpressive, I got a bug report about a crash which
>  was due to construction order of its global objects, which let to
>  Proto's expressions-are-aggregates design. If an object must be a
>  namespace scope -- and function objects must if they are to truly behave
>  as regular functions -- I won't use them if they need dynamic
>  initialization.
>

 Of course I appreciate the general benefit of statically initialized
function objects (i think you and David Abrahams showed me the trick
used to even have them initialized in headers).

I just wanted to know if there was generally necessary  to have
*stateful* function objects: when the simple syntax:

  my_function_type f = {};

isn't enough? I.e., when you actually need to put anything in those
braces? I honestly do not know.

I never had this necessity, but both you and Shunsuke have certainly
worked with more complex function objects than I did.

-- 
gpd