Re: [boost] functional.hpp and mem_fun.hpp (was [Review] bind)

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-31 08:17:37

From: "John Maddock" <John_Maddock_at_[hidden]>
> > As far as mem_fun.hpp is concerned, I'll simply rename it to mem_fn.hpp.
> > This debate has exceeded its quota. ;-)
>
> I'm sorry we can't find common ground here, to me, having three kinds of
> mem_fun is not a good solution.

The circle is now complete. ;-) My original intention to replace
{std,boost}::mem_fun has met a strong opposition. I now consider the
arguments quite convincing, so I decided to rename mem_fun.

> To be honest I'm not that sure why you're so hung up on auto_ptr here -

Here is why:

"template<class R, class T, class A1> implementation-defined-3 mem_fn(R
(T::*pmf) (A1))

Returns: a function object f such that the expression f(t, a1) is equivalent
to (t.*pmf)(a1) when t is an l-value of type T, (get_pointer(t)->*pmf)(a1)
otherwise.

Throws: Nothing."

This is how mem_fn is defined. My implementation doesn't _strictly_ conform
since it introduces additional copies for by-value arguments, but in general
the Standard allows a bit of freedom as far as temporaries are concerned. In
contrast, taking an auto_ptr by reference would mean that f(t, a1) would not
compile whereas (t.*pmf)(a1) would, and this is unacceptable.

I don't believe that optimizations - such as using
call_traits<>::param_type - should be part of the interface. As long as the
'effects' are the same, the implementor is free to use whatever tools are
available to him/her to improve the efficiency of the implementation.

> auto_ptr has somewhat strange semantics and in cases like this I think
it's
> acceptable for code not to work with it - consider that:
>
> 1) the non-bound parameter passed to std::binder1st can not have move
> semantics (because it's passed through by const reference).
> 2) the rationale for binder1st passing parameters through by reference is
> efficiency (it prevents an unnecessary copy), I've never seen a good
> rationale why ptr_fun and mem_fun don't follow the same rule (as the boost
> versions do).

I've outlined something close to a rationale for this decision in a previous
post. Basically, in the absence of information about which method for
parameter passing is 'best', it's reasonable to choose the const reference.
In these cases, however, we do have information which method has been chosen
by the function designer, so it's reasonable to use it.

Of course had call_traits been available at the time ptr_fun and mem_fun
were designed, they could have been different. I don't know.

> 3) the boost bind lib can't pass through a temporary auto_ptr either
> (because parameters are deduced as non-const-references), remind me who
> wrote that one again? ;-)

;-)

I view this as an unfortunate limitation of the current implementation of
Bind (and an unfortunate limitation of C++ that prevents a pure library
solution to this problem.)

Besides, mem_fn is not affected by bind design choices. It's a separate
component. I wouldn't be surprised to find Lambda taking advantage of it
some day. ;-)

--
Peter Dimov
Multi Media Ltd.