Re: [boost] boost bind/functional/reference wrapper/mem_fn

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-01-30 15:08:30

From: "Yitzhak Sapir" <ysapir_at_[hidden]>
> Now, regarding the BOOST_BIND_NO_PLACEHOLDERS macro, at first I thought
> it was a mechanism for solving the precompiled headers.  In this view,
> you use BOOST_BIND_NO_PLACEHOLDERS in a precompiled header, and then
> include boost/bind/placeholders.hpp in the cpp.

Yes.

> Peter apparently has a different issue, being that some people may not
> like _1 .. _9, and for those people they can use boost::arg<1> etc.

And yes.

> Given this, I'm unsure what their status is - Staying but controversial,
> May be removed if outvoted eventually, Scheduled to be removed in later
> versions or what.

Here to stay.

There are two other reasons for the separate headers:

* making the placeholder types 'public' i.e. at boost:: enables visit_each()
users to recognize them;

* separating the placeholders makes it possible for other libraries to reuse
them.

> I have no problem with _1 .. _9 as names.  They are concise, although up
> until now the void-returns problem got me to use bind1st/bind2nd and
> functional (which I had modified to be able to use void returns), so I
> never needed them for anything truly concise.  There was also a problem
> in that they couldn't have functors as a first parameter (at least not
> in my experience, which, if I couldn't make it work with just a few
> changes, I tried to work around it as quickly as possible, and in this
> case, went to bind1st/bind2nd).

Sorry, what was the problem again? ;-)

> Also, I think it was a Scott Meyers' article that discussed not being
> able to use standard algorithms in functions like ptr_fun because they
> may include additional default parameters, which ptr_fun may not be
> aware of (I hope I'm getting this right).  It is hard for me by looking
> at the code to make certain (compounded by the fact I can't find the
> article right now) so would boost::bind be able to be a workaround for
> such a problem?

Unfortunately not. Once a function converts to a function pointer, there is
no way to determine the default arguments, if any.

The only way to do it portably is to write a forwarding function. I don't
like it but this is what the standard says.

Some compilers "remember" the default arguments and allow such uses but this
is non-standard (and may be classified as a bug.)