From: Brian McNamara (lorgon_at_[hidden])
Date: 2004-02-19 13:10:46
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_at_[hidden])
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk