RE: [boost] more on boost::mem_fn

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2001-11-23 09:16:24

Peter Dimov wrote:
> > While in many senses this is true, without deeper explanation of 
> > all differences/similarities between 'boost::mem_fn' and its std 
> > counterparts, the sentence can lead one to a conclusion that 
> > 'boost::mem_fn' can be used as a replacement of 'std::mem_fun' 
> > and 'std::mem_fun_ref', i.e. that one can use the former one 
> > everywhere in place of the latters, which (as we know) is
> > not true.
>
> What particular differences do you have in mind?

Well, you've clarified some of the issues below, but basically after the
statement that "boost::mem_fn is a generalization of the standard functions
std::mem_fun and std::mem_fun_ref", I would like to see a disclaimer that
still boost::mem_fn is not a complete replacement of those std components,
because there are cases when it has no choice but to lie in it
'[first_]argument_type' typedef, and in these cases you might have to resort
to the what the standard library has to offer. For example, this doesn't
compile:

    int print(std::string const&);

    struct my
    {
        std::string name() const;
    };

    boost::compose_f_gx(
          std::ptr_fun(print)
        , boost::mem_fn(&my::name)
        )(my()); // cannot convert parameter 1 from 'my' to 'my const*'

and this does:

    boost::compose_f_gx(
          std::ptr_fun(print)
        , std::mem_fun(&my::name)
        )(my());

Which is not a big issue (you may even argue that one should use boost::bind
instead of boost::compose_f_[...] here and everywhere :). But see, you
cannot just say to your team "listen, boost::mem_fn is more general, and it
also works with both smart pointers and references, so instead of writing
boost::mem_fun[_ref] in one place, std::mem_fun[_ref] in another, and yet
boost::mem_fn in third one, let's just consistently use boost::mem_fn
everywhere" - because it just won't work this way (at least not until the
day you get rid of all these binders, composers, etc.). So it would be nice
if the library documentation acknowledged that fact (so one doesn't have to
re-discover it herself). 

> All of these match. The [first_]argument_type constness is a 
> defect in the standard. 

Ok, I agree that probably there is no need to document this.

> The differences in parameter passing are between boost::mem_fn 
> and boost::mem_fun[_ref], not between boost::mem_fn and 
> std::mem_fun[_ref].

I see how it works now.

Aleksey