[boost] Re: A mem_fn thought

From: David Abrahams (dave_at_[hidden])
Date: 2003-09-17 15:52:03

"Peter Dimov" <pdimov_at_[hidden]> writes:

> 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)

I broke Metrowerks??

> _but_ the outer bind doesn't know that.
>
> A "quality implementation" of std::bind is expected to compile the
> code.

<scratch??> I thought you just got through explaining how that's
impossible because of the exposed result_type?

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

Why?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com