Joel de Guzman wrote:
On 1/21/2011 8:39 PM, Michel MORIN wrote:
I have another question about Phoenix 3. Is the copy assignment of Actors no-op, or does it really copy the contents?
Actor a; Actor b = ...; a = b; // no-op?
It should copy the contents. Thomas?
Not really. It needs to create the assign actor (that means the expression template representing the assignment operation. It is neither a no-op nor is the assignment "executed". Remember the stuff about phoenix being lazy ;)?
[snip] (some code...) Michel, did you compile and run the code? It works like a charm. Here is why: Iterator is not a phoenix actor. It is a boost::transform_iterator<Phoenix Actor, int*>.
The only requirement the phoenix actors have to fullfill are those of a UnaryFunction. The type UnaryFunction must be Assignable, Copy Constructible, [...] A Phoenix Actor can never be (fully) Assignable. However, apart from this:
Actor a; Actor b = ...; a = b; // no-op?
It fulfills every other requirement of the Assignable concept[1].
(In Phoenix 2, boost::phoenix::value<T> is not default constructible, and so the above iterator does not satisfy the ForwardIterator requirements too.)
That is true. phoenix::value is not default constructible. While it is easy to make it so, I'm not sure it is a good idea as it will potentially break existing code which holds values that are not default constructible. I'd argue that phoenix3 should follow.
In phoenix 3 most actors are PODs ... making them default constructible.
OTOH, I think a good compromise is to allow default construction on primitive types and POD structs. That will solve your problem. I can do that now with phoenix-2.
Regards,