Re: [Boost-users] [proto] a question on assignment operators

Subject: Re: [Boost-users] [proto] a question on assignment operators
From: Eric Niebler (eric_at_[hidden])
Date: 2009-08-24 22:46:17

Maurizio Vitale wrote:
>>>>>> "Eric" == Eric Niebler <eric_at_[hidden]> writes:
>     >> If that's true, then my followup question was whether it is ok to
>     >> perform the assignment the way I was doing it, casting away
>     >> const.
> 
>     Eric> In short, it shouldn't be necessary. You're using
>     Eric> proto::flatten and fusion::fold. Somewhere in there the
>     Eric> constness is getting messed up. You should file a bug.
> 
> I'm afraid at this point I don't understand enough of the problem in
> order to file an useful report with the fusion developers. I probably
> wouldn't be able to produce a small fragment exposing the bug and not
> involving proto.
> 
> I can certainly send them the code as it is, if you think it would be
> useful. Is the boost devel mailing list the appropriate place?

It could very well be a proto bug, not a fusion one, so go ahead and 
file it against proto and include the code you first sent.

>     >> The other question I had was on what was the reason for
>     >> explicitely disable assignment operators in grammars. This is
>     >> something you do in many of your examples
> 
>     Eric> I do? Which examples? I don't see it.
> 
> lambda.hpp:        // Use a grammar to disable Proto's assignment operator overloads.
> mixed.cpp:         // A grammar which matches all the assignment operators,
> vector.cpp:        // A grammar which matches all the assignment operators,

Ah. See below.

>     >> , but doesn't seem to make a difference in my code (e.g. having
>     >> an operator= in my expression seems to stop proto from building a
>     >> larger tree including the '=' anyhow, without needing to disable
>     >> it explicitly)
> 
>     Eric> I'm afraid you've lost me again.
> 
> It seems like defining an operator= on extended expressions is all you
> need in order to prevent proto from using its own overload. Hence I was
> wondering what was the reason for disabling the assignment operators in
> the grammar, like done in the examples mentioned above.

For the DSELs defined in those examples, we wanted the assignment 
operators (=, +=, /=, etc.) to actually do useful work rather than build 
still larger expression templates. Hence, proto's ET-building overloads 
are disabled. If you're not using +=, /=, etc. in your DSEL you can 
safely ignore it (i.e., not bother disabling them via SFINAE). And for 
operator= (a special case because it can only be defined as a member 
function), defining it as you have is sufficient to hide the one proto 
defines.

HTH,

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com