Boost logo

Boost :

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

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

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at