[Fusion] fold takes state by cref. Why ?
Why is the State passed by const reference ? I have a couple of use case (like using fold to access the element (i0,...,in) of a fusion sequence of pointer to ... pointer to T array) where I need to be able to discriminate the constness of the State to forward to the proper PFO overload of operator(). Is there any intrinsic stuff I am missing ?
On 10/04/2011 16:30, Joel Falcou wrote:
Why is the State passed by const reference ? I have a couple of use case (like using fold to access the element (i0,...,in) of a fusion sequence of pointer to ... pointer to T array) where I need to be able to discriminate the constness of the State to forward to the proper PFO overload of operator().
Is there any intrinsic stuff I am missing ?
Can you not use boost::ref ?
On 4/10/2011 10:30 PM, Joel Falcou wrote:
Why is the State passed by const reference ? I have a couple of use case (like using fold to access the element (i0,...,in) of a fusion sequence of pointer to ... pointer to T array) where I need to be able to discriminate the constness of the State to forward to the proper PFO overload of operator().
The type of 'State' may change on each iteration, so in general, there really is no sense in having a mutable 'State'. It is essentially pure FP. Having said that, there is no technical reason why we can't allow a non-const state -it's just another overload. It might also be useful for cases where the 'State' type remains constant. I added such overloads. I'll commit as soon as all tests pass. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On 11/04/11 01:42, Joel de Guzman wrote:
On 4/10/2011 10:30 PM, Joel Falcou wrote:
Why is the State passed by const reference ? I have a couple of use case (like using fold to access the element (i0,...,in) of a fusion sequence of pointer to ... pointer to T array) where I need to be able to discriminate the constness of the State to forward to the proper PFO overload of operator().
The type of 'State' may change on each iteration, so in general, there really is no sense in having a mutable 'State'. It is essentially pure FP. Having said that, there is no technical reason why we can't allow a non-const state -it's just another overload. It might also be useful for cases where the 'State' type remains constant. I added such overloads. I'll commit as soon as all tests pass.
Regards, Perfect :)
More generally it could be nice to have mutable version fo stuff like zip (zipign two reference of sequence) or for_each. FP is dandy and all but like with Phoenix, we live in a mutable language so we may need this.
participants (3)
-
Joel de Guzman -
Joel Falcou -
Mathias Gaunard