Boost logo

Boost :

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk