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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-28 06:06:53

From: "Mark Rodgers" <mark.rodgers_at_[hidden]>
> From: "Peter Dimov" <pdimov_at_[hidden]>
> >
> > I'm confused. Is this a bug in, or a feature of, functional.hpp?
>
> We don't have bugs - only undocumented features.  :-)
>
> However this is actually a documented feature, and is one of the
> two reasons boost::mem_fun exists.

I was under the impression that the standard mem_fun used a const reference
and that your boost replacement avoids the reference to reference problem.
If this were the case, your version would be a standard-conforming
implementation that happens to use call_traits as an optimization.

However, std::mem_fun1_t takes its parameter by value. This means that it
works for types with destructive copy semantics, whereas your version does
not. This means that boost::mem_fun does not conform.

That's why I asked whether this issue was considered.

> The other reason was to fix a
> defect regarding constness of first_argument_type in the
> const_mem_fun_t family - something I see you have also done.

Yes, this is an obvious defect.

> Personally I think it would be silly to have yet another
> std::mem_fun replacement with another name.  I really hope I can
> convince you to use call_traits so we can amalgamate the two.

I can't use call_traits; using call_traits changes the semantics of the call
thanks to that wonderful invention called std::auto_ptr. ;-) The interface
should not specify optimizations, only behavior.

> Failing that, I'd much prefer to just see your mem_fun relegated
> to an implementation detail of bind, since I don't honestly think
> it has much value on its own.

As Kevlin Henney likes to say, "express independent ideas independently."
Bind doesn't have anything to do with member functions. Its only purpose in
life is to bind arguments, not to turn member function pointers into
function objects. The shorthand notation is only a convenience.

> In fact I think it has a negative
> impact so this would be my first choice if I didn't think I'd
> already lost that battle.

This is a more interesting statement. What is the negative impact of mem_fn?

> Adding it as boost::mem_fn would be very much my third choice.

This is rapidly becoming my first choice. Trying to call it mem_fun was a
mistake (from a political if not technical point of view.)

--
Peter Dimov
Multi Media Ltd.