Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-27 07:14:35


From: "Mark Rodgers" <mark.rodgers_at_[hidden]>
> > I'm now convinced that your original idea - having functional.hpp
> > include mem_fun.hpp - is the best solution.
>
> Yes, I think that is probably best if we can reconcile our differences.
>
> Given your analysis of compiler compatibility and compile times, I
> personally don't think that is a major issue, but I would be interested
> to hear from others on that.
>
> The other issue is use of call_traits instead of simple pass by value.
> I refuse to budge on this. The call_traits documentation says param_type
> 'Defines a type that represents the "best" way to pass a parameter of
> type T to a function.' I absolutely insist that we use this "best" way.
> If passing a double by value is best, I hope call_traits will define
> param_type accordingly on those platforms. If it doesn't then that's a
> bug in call_traits, not functional.

I understand your point of view.

Even without delving into the dangerous topic of what is the most efficient
way to pass T to a function and can it be determined given only the type T
(IOW is it possible for call_traits to ever satisfy its contract) there is
one additional issue to address.

What is the "best" way to pass an std::auto_ptr to a function?

(I use std::auto_ptr as a shorthand for "an user-defined type with
std::auto_ptr-like destructive copy semantics.")

Obviously there is no best way since the two alternatives have radically
different meanings.

This doesn't affect functional.hpp::mem_fun since std::mem_fun(pmf) always
takes its arguments by const reference, and hence, doesn't support by-value
auto_ptr arguments. The only thing to watch out for is to not turn a
by-const-ref auto_ptr to a by-value auto_ptr. ;-)

I now realize that - by my definition of mem_fun.hpp::mem_fun - I have
introduced different semantics that are not compatible with std::mem_fun
(since I guarantee that mem_fun(pmf) will work with auto_ptr arguments.)

All this leads me to the conclusion that I made a mistake; my mem_fun is not
a replacement for std::mem_fun. So I will rename it to mem_fn (and the
header will become boost/mem_fn.hpp.)

> I would also comment that passing an expensive-to-copy object by value is
> not necessarily completely unheard of. If I need to make a mutable copy
> for some reason, I will usually write
>
> void f( BigObject b ) { /* modify b */ }
>
> rather than
>
> void f( const BigObject &b ) { BigObject bb(b); /* modify bb */ }

I used to do that, too. Not anymore. ;-)

--
Peter Dimov
Multi Media Ltd.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk