Re: [boost] [Phoenix-3] Is Actor assignable?

Subject: Re: [boost] [Phoenix-3] Is Actor assignable?
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-01-22 07:17:28

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,

Thomas

1: http://www.sgi.com/tech/stl/Assignable.html