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

From: John Maddock (John_Maddock_at_[hidden])
Date: 2001-08-31 06:40:41

Mark:
>Yes, I agree that seems a problem.  John, can you please expand a bit as
to
>why you see a problem with call_traits<auto_ptr<T> >::param_type being
>auto_ptr<T>?  I can't see it myself.

Simply that the semantics of pass-by-reference and pass-by-value are
radically different for auto_ptr, if someone used call_traits in a generic
class/function expecting pass-by-reference semantics, and then the user
passed an auto_ptr in, they may be in for a surprise. Having said that I
can't actually think of a good example, so maybe it's a non-issue.

Peter:
> 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.

To be honest I'm not that sure why you're so hung up on auto_ptr here -
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).
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? ;-)

Whatever, do what you think is best.

- John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/