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);