On Thu, Feb 19, 2004 at 03:26:12PM +0200, Peter Dimov wrote:
Brian McNamara wrote:
A number of people have voiced similar complaints, and I am gradually being worn down. I think one of the reasons I resist it is that I don't like how boost::lambda has dealt with the issue. Notably, examples like
// From 5.3.2 of the lambda docs bind(&A::set_j, a, _1)(k); // a.j == 0, as a copy of a is modified bind(&A::set_j, _1, 1)(a); // a.j == 1
where reference-versus-copy depends upon the precise "timing" of binding a function argument to a value, ...
There is no "precise timing" issue here, the rule is simple. Every argument passed to bind() is copied, whether it is &A::set_j, a, _1, or 1.
I do understand this. I am looking from another perspective. bind() lets me pass some of the arguments to a function "now", and the rest "later". In the example above, if I pass "a" now and "k" (1) later, I get one behavior, but if I pass 1 now and "a" later, I get another. This is counter-intuitive, from my perspective.
An example that may illustrate your point is
std::cout << _1
where 'std::cout' is taken by reference, versus
_1 << 1
where '1' is copied. But std::cout << _1 is just a convenience spelling for ref(std::cout) << _1, which is reference-consistent. It's too prevalent in motivating examples to not warrant special treatment. :-)
Given the rest of the boost::lambda design, I do agree with the special treatment of ops like << and +=. -- -Brian McNamara (lorgon@cc.gatech.edu)