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

From: Yitzhak Sapir (ysapir_at_[hidden])
Date: 2002-01-31 04:37:58

-----Original Message-----
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.
------------------

I would have wished your answer was no and yes, or yes and yes but the
workaround will still be implemented.  Precompiled headers should be
something that is independent of the way the headers were coded.  I
shouldn't have to write my code assuming that precompiled headers may be
used.  Furthermore, there is no predefined compiler macro that would
allow me to determine whether precompiled headers were specified.  If I
were a library writer and wanted to use bind, which I'm not, I would
also have to pass on this restriction to users of the library: "If you
use my library, you cannot compile with precompiled headers unless you
put #define NO_PLACEHOLDERS before the header file and add the include
to any cpp that makes use of my library.  This is quite an uncomfortable
restriction.

----
* making the placeholder types 'public' i.e. at boost:: enables
visit_each()
users to recognize them;
----
what is visit each?
--------
> 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? ;-)
---------
Well, the precompiled headers issue above, and the syntax for passing
functors (such as std::equal_to) to bind.  Maybe it works now.  I'll
check it out.
----------
> 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.)
[...] because bind cannot access the defaults for some_stl_func. Of
course you
can supply the defaults yourself but then you are back to nonportability
land.
I don't know whether this is a practical issue. Has anyone encountered a
standard library function with such a signature?
-----
According to the article almost all functions were to have such
signatures.  This is supported by what I see in sites I visit for a copy
of the working draft, as in the following.  If default values were the
only problem, you could determine the number of arguments using the bind
function call itself.  However, since you could also have additional
function signatures, I guess there might be no way to solve this:
An  implementation  can declare additional non-virtual member function
  signatures within a class:
  --by adding  arguments  with  default  values  to  a  member  function
    signature;(Hence, taking the address of a member function has an
unspecified
   type) The same latitude does not extend to  the  implementation of
virtual or
   global functions, however.
  --by  replacing a member function signature with default values by two
    or more member function signatures with equivalent behavior;
  --by adding a member function signature for a member function name.
Info: http://www.boost.org  Send unsubscribe requests to:
<mailto:boost-unsubscribe_at_[hidden]> 
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/