Re: [boost] Re: A mem_fn thought

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-09-17 07:11:35

Howard Hinnant wrote:
> On Sep 16, 2003, at 5:48 PM, David Abrahams wrote:
>
>> It would be convenient for me if mem_fn(pm) could be *called* to set
>> the data member, as in:
>>
>>      X x;
>>
>>      mem_fn(&X::member)(x, value);
>>
>> That way, bind(&X::member, _1, value) would be useful.
>
> Could you expound on your convenience factor with respect to what you
> have proposed, and the following:
>
> template <class T>
> struct assign
> {
> typedef T& result_type;
>
> template <class U>
> T& operator()(T& t, const U& u) const
> {return t = u;}
> };
>
> ...
>
> bind(assign<T>(), bind(&X::member, _1), value)(x);

Can your std::bind do the above? ;-)

The problem here is that mem_fn(&X::m) can only expose a single result_type,
and the choice is between M or M const&, neither of which allows assignment.
boost::mem_fn exposes M const& as its result_type. It _returns_ a proper
non-const reference when its argument is (a pointer to) non-const, though,
except on MSVC <7.0 and, ironically, Metrowerks (a recent patch by Dave)
_but_ the outer bind doesn't know that.

A "quality implementation" of std::bind is expected to compile the code.

So in summary, the extension makes sense for boost::mem_fn and boost::bind,
and the std:: case is less clear cut.