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

Subject: Re: [boost] [Phoenix-3] Is Actor assignable?
From: Joel de Guzman (joel_at_[hidden])
Date: 2011-01-22 08:02:16

On 1/22/2011 8:17 PM, Thomas Heller wrote:
> 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 ;)?

No! That's not the case here. There *is* still the immediate assignment
operator being called when two actors are of the same type (e.g.
when lhs and rhs are phoenix values). In these cases, a *is*
assigned to *b*. Thus, for values, the contents are copied.
Ditto for copy construction of course.

>> [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.

Which *may* break existing code as mentioned above. Whether that's a big
deal or not, I'm not so sure.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://boost-spirit.com