From: Dill, John (john-dill_at_[hidden])
Date: 2004-05-07 09:30:11
"Douglas Gregor" <gregod_at_[hidden]> wrote in message news:<200405061958.52886.gregod_at_[hidden]>...
> On Thursday 06 May 2004 05:32 pm, Dill, John wrote:
> > I believe that this can be done, but doesn't justify whether it should be
> > done. There are several issues that I see at the moment.
> > A. Changes the semantics of everyone's bind and mem_fn, no biggy there
> > ;-). B. Pass by value is silent, not sure how many copies of the argument
> > will be generated if pass-by-value.
> > But at the same time there is an advantage.
> > a. You can use literals in calling your bind functions.
> > What do you all think?
> I don't like the change.
> Ideally, bind(f, _1, _2, _3)(x, y, z) would be exactly equivalent to f(x, y,
> z). The current bind() implementation gives us nearly this equivalence
> because it passes by reference, except that we get a failure at compile time
> if one tries to pass a literal. Going to passing by value would take us
> further from that ideal equivalence.
I see your point. But, what if instead of argument_traits being pass by value, it by default passes by T const&? What could be done is to have the bind_t arguments be passed by const reference, and then use reference_wrapper to do type-selection to pass by reference. It still supports literals, and passes by T const& when it can, but everything that is passed by reference must have a ref( object ). The compiler would fail if you try to pass a reference without a reference_wrapper because it by default tries to pass a T const&. This wouldn't require the 2^N overloads but would require you to do a ref( object ) for everything passed by reference. This might also be a workaround for those compilers that don't support T& and T const& overloading.
I think that this should be addressed, either through overloading, or maybe this idea might be feasible. I think the implementation of this aspect of bind is worth doing.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk