Boost logo

Boost :

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
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,



Boost list run by bdawes at, gregod at, cpdaniel at, john at