From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-09-17 16:40:56
David Abrahams wrote:
> "Peter Dimov" <pdimov_at_[hidden]> writes:
>> 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
> I broke Metrowerks??
No, you only broke MSVC 7.0. ;-)
#if !defined(BOOST_MSVC) || (BOOST_MSVC > 1300)
#if !BOOST_WORKAROUND(BOOST_MSVC, < 1300) && !BOOST_WORKAROUND(__MWERKS__,
effectively applying the VC7- workaround to all Metrowerks versions IIUC.
The code that is surrounded by the #if block is:
R & operator()(T & t) const
which is the non-const return used in cases like
mem_fn(&X::m)(x) = 5;
Presumably you had good reasons for the patch; I don't remember MW failing
one of the tests though, so it must have been a case that is not covered. We
need at least two more test cases, one with the code that lead to the patch,
and one with the above example.
>> A "quality implementation" of std::bind is expected to compile the
> <scratch??> I thought you just got through explaining how that's
> impossible because of the exposed result_type?
No, it's not impossible. The standard bind is required to do
argument-specific type deduction via result_of, and result_of must do the
right thing for mem_fn(&X::m) since it's a function object generated by the
boost::bind doesn't do type deduction.
>> So in summary, the extension makes sense for boost::mem_fn and
>> boost::bind, and the std:: case is less clear cut.
Because with boost::bind there is no good alternative, whereas in
bind(assign(), bind(&X::m, _1), value)
may be considered acceptable; it is a matter of drawing the proverbial line