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

Maurizio Vitale wrote:

...

...

...

...

...

"Eric" == Eric Niebler 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