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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-09-03 06:03:01

From: "John Maddock" <John_Maddock_at_[hidden]>
> >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.
> <
>
> Which is surely the core of the issue - the intent is that
> call_traits<>::param_type is just "one of the tools that the implementor
> uses to improve the efficiency of the implementation", it isn't supposed
to
> alter semantics at all, if it does then it's a defect.

That's only one of the issues. ;-)

1. Naming: should mem_fn be named mem_fun?

A: Yes, if it's going to replace std::mem_fun, no otherwise. My original
intention was to replace std::mem_fun, now I see that this is, well, not
reasonable. It's true that this adds one more 'mem_fun' function, but I
don't see this as a real problem. The similar function names reflect their
almost identical semantics.

2. Interface: should mem_fn be defined as using call_traits, as Mark's
version is?

A: No, I don't believe that it should be. The implementation is allowed to
assume that a chain of copy constructors has the same effect as a single
copy constructor, so it's within its rights to optimize out the double copy.
No mention of call_traits is necessary. See, for example, the resolution of

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#181

3. Implementation: should mem_fn use call_traits internally to avoid double
copies?

A: With my implementor hat on, I decided that this optimization does not pay
off. I don't want to imply that call_traits is not useful in general; simply
that I don't consider it the appropriate tool for this particular situation.

Bottom line, do you want mem_fn and bind in the CVS or not? We can always
revisit the issues at a later date when we have more information.

--
Peter Dimov
Multi Media Ltd.