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

From: Yitzhak Sapir (ysapir_at_[hidden])
Date: 2002-01-30 14:52:30

No, I don't think you're not missing something.  Although I wasn't sure
what unnamed namespaces were in the beginning, by the time I replied, I
pretty much knew, just wasn't sure which would be best, and had this
code that had compiled and run in my tester and which I was afraid to
modify now that I had a working code.  Also, if it were #ifdef MSVC'd
then it might have been less (or in contrast more) confusing to put it
in an unnamed namespace.

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.

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

Or you could adopt both views.

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).  Just for where bind1st/bind2nd would
work (3 params or more), in which case, I usually had the functor take
up several lines anyhow, with each parameter given a position on a
separate line, something like:
        if ( std::find_if(
                cont.begin(),
                cont.end(),
                boost::bind(
                        &some_class_name::some_operation,
                        _1,
                        some_value,
                        another_value
                )
        ) == cont.end())
        {
                // some action
        }
which is more readable to me since by the time you get to
some_class_name you're usually past the readable left portion of the
screen.

Would my workaround be used and the BOOST_BIND_NO_PLACEHOLDERS macro
remain for just those who dislike _1 .. _9?  In either case, what is
their status (see above possible partial list of choices).

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?

Is it possible that boost::bind would or could implement some partial
specilization to allow a user to do some functor_traits type thing to
determine how many arguments the functor is supposed to take?

-----Original Message-----
From: Fernando Cacciola [mailto:fcacciola_at_[hidden]]
Sent: Wednesday, January 30, 2002 9:19 PM
To: boost
Subject: RE: [boost] boost bind/functional/reference wrapper/mem_fn

----- Original Message -----
From: Yitzhak Sapir <ysapir_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, January 30, 2002 11:39 AM
Subject: RE: [boost] boost bind/functional/reference wrapper/mem_fn

> [...]
> namespace
> {
>     inline boost::_bi::arg<1> _1() { return boost::_bi::arg<1>(); };
>     inline boost::_bi::arg<2> _2() { return boost::_bi::arg<2>(); };
>     inline boost::_bi::arg<3> _3() { return boost::_bi::arg<3>(); };
>     inline boost::_bi::arg<4> _4() { return boost::_bi::arg<4>(); };
>     inline boost::_bi::arg<5> _5() { return boost::_bi::arg<5>(); };
>     inline boost::_bi::arg<6> _6() { return boost::_bi::arg<6>(); };
>     inline boost::_bi::arg<7> _7() { return boost::_bi::arg<7>(); };
>     inline boost::_bi::arg<8> _8() { return boost::_bi::arg<8>(); };
>     inline boost::_bi::arg<9> _9() { return boost::_bi::arg<9>(); };
> }
>
> This way it can remain one header with no extra defines based on
whether
> you want/don't want precompiled headers.  Or is something wrong with
> this code?
>
Jus a note: The definitions of the inline functions _X() are inside an
unnamed namespace.

Unless I'm missing something, it is required that inline functions be
declared inside an unnamed namespace.
Just for the records, I'll explain this issue in some detail:
[...]