Boost Users :
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.
> 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
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.
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.initialize(args) forwards to
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);
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net