Hi Thorsten,
Looking at the code, it seems boost::bind uses non-const reference for operator() -- the actual forwarding -- and by-value for arguments to 'bind' itself.
I must admit I don't get that. I extended rhe example to show the problems (see attachment). As you point out, bind() *silently* compiles code that would not compile if one called the original function with those arguments. IMO, *very* trouplesome.
What I was saying is that bind uses non-const reference for operator(), so if you use: bind(foo, _1)(i); bind( foo, _1 )(ci); then it will work ok. In fact, first one compiles and the second one does not. And, BTW, "foo(i)" compiles just fine too, so your 'proper_forward(i)' should compile too, but it does not. As for bind(foo, i)(); bind(foo, ci)(); I don't have any opinion yet.
What I think about it is that const-reference prevents you from passing non-const references to constructors of objects you put to container.
only in the sense that you need to use boost::ref<>
Ah, since you only forward arguments boost::ref<> will work transparently and you never need to unwrap_reference in the library code.
OTOH, with non-const references you'd break the passing of integer literals --
any "literal", in fact.
Yes, I've used "integer" for example only.
Maybe, you really should support ref<> for passing non-const references.
Depends on what you mean by support :-) It's already supported by using ref<>. I think that is ok; afterall, reference arguments should not be used that much thoughout code.
I agree. In fact, my previous post was just a long-winded way to say that while in general non-const references might be preferrable, for this library const references are better. - Volodya