Re: [Boost-users] [accumulator] extract_result during initialization

Subject: Re: [Boost-users] [accumulator] extract_result during initialization
From: er (erwann.rogard_at_[hidden])
Date: 2009-03-05 15:02:05

Eric Niebler wrote:
> er wrote:
>> er wrote:
>>  I would have
>>> thought that this is feasible because accumulator_set initializes (a) 
>>> before (b), but apparently b.x_ is initialized with a garbage value.
> <snip>
> 
> It's not going to work without major surgery. The accumulator_set has 
> one data member, which is a Fusion list of all the accumulators in the 
> set. It is not initialized in-place; rather, a separate routine creates 
> and initializes a Fusion list, which is then copied into the 
> accumulator_set in the last step. That means you'll get garbage if you 
> try to extract results from an accumulator_set while it's being 
> constructed.

Thanks , that will save me trying un-necessarily.

> 
> It would be nice if the list were initialized in-place, but I'm not sure 
> how to do that, and I don't have the time to look into it. Please file a 
> feature request. 

OK.

In the mean time, is there any way you can change your
> design so that it doesn't depend on the ability to extract results from 
> a partially constructed accumulator set? 

Actually, I extracted the backbone of Accumulators to manage more 
general dependent features. Amongst other things, I dropped the 
dependency on RealType and the new definition of visitor is

visitor::operator()(feature) calls f(feature,args), where f  and args 
are passed in the constructor of visitor.

I simply delay initialization until the set is constructed:

set_type set;
set.initialize(args) forwards to 
set.visit(initialize_op(),params()(*this,args)),

where initialize_op::operator()(feature,args) calls feature.initialize(args)

but instead, I could probably remove the burden of having to define 
initialize for each feature with something like:

feature = feature_type(args);