Boost logo

Boost :

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2001-11-23 12:15:20


Peter Dimov wrote:
> That's why the argument_type typedefs aren't a part of the formal
> specification. I've left them in 'cause they can't really hurt.

So, we are relying on the unspecified behavior? Ouch! :)

> boost::mem_fn is simply not intended to be composed or bound
> by something that needs typedefs.

Yeah, that's what we've figured :).

> > 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());
>
> Did you mean std::mem_fun_ref?

Yes, that's what I meant.

>
> > Which is not a big issue (you may even argue that one should use
> > boost::bind instead of boost::compose_f_[...] here and everywhere :).
>
> Yes, this is what I'd argue.

We would love to, but besides educational issues there are also some
technical problems :(. For example, the following code does not compiles on
MSVC6.5:

#include "boost/bind.hpp"
#include <string>

struct something
{
    int id() const;
};

struct to_string
{
    typedef std::string result_type;
    std::string operator()(int) const;
};

int main()
{
    something* s;
    boost::bind(to_string(), boost::bind(&something::id, _1))(s);
    return 0;
}

And AFAIK it should. The 'to_string()' function object is the main source of
troubles here. I haven't got time to look into details of what's happening
here, though.

> boost::mem_fn does two things:
> first, allows you to write
>
> std::for_each(v.begin(), v.end(), boost::mem_fn(&Shape::draw));
>
> for a container of mem_fn-aware objects, and second, provides
> a component (along with documentation) that may be reused
> whenever you (meaning a library author) need transparently to
> treat a pointer to member function as a function object. For
> example, it allows you to define (and easily document
> 'by reference') a for_each such that
>
> for_each(v.begin(), v.end(), &Shape::draw);
>
> is equivalent to the above.

How about adding the above paragraph to the docs? :)

> > So it would be nice if the library documentation
> > acknowledged that fact (so one doesn't have to
> > re-discover it herself).
>
> OK, I'll think about it. ;-)

Thank you!

BTW, if I haven't said it yet, I think that both your libraries are great
:).

--
Aleksey

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