boost bind/functional/reference wrapper/mem_fn

From: Yitzhak Sapir (ysapir_at_[hidden])
Date: 2002-01-27 13:22:09

Hi.  I would like to make a request as a user: Can all the
functions/classes in the subject line (and perhaps others) be defined
with a macro BOOST_BIND_INLINE or BOOST_FUNCTIONAL_INLINE, etc.  Then at
the top of the headers define the macro as either
#ifndef BOOST_BIND_INLINE
#define BOOST_BIND_INLINE inline
#endif

or
#ifndef BOOST_BIND_INLINE
#define BOOST_BIND_INLINE BOOST_INLINE
#endif

with BOOST_INLINE being defined in the same way in some general header
file.

This would apply to both  inlined template functions and any function
that would be inline, even if specifying inline is unnecessary.  This
would allow me to define, on MSVC, the macro to __forceinline in cases
that I wanted it to really try its best to inline.  (All of the above
are good examples of such cases).  Furthermore, it might seem that, once
these functions are inlined, the compiler may have an easier time
optimizing out variables if for example, in functional.hpp, mem_fun_t
was declared as follows:
    template <class S, class T>
    class mem_fun_t : public std::unary_function<T*, S>
    {
      public:
        BOOST_FUNCTIONAL_INLINE explicit mem_fun_t(S (T::*p)())
            :
            ptr(p)
        {}
        BOOST_FUNCTIONAL_INLINE S operator()(T* p) const
        {
            return (p->*ptr)();
        }
      private:
        S (T::*const ptr)();
    };
Which defines ptr as const in respect to the class.  I'm not sure, but
I'd guess this would help it optimize...

Another issue with regards to bind is that when I use the bind in
several statically linked libs, I get multiple definition errors, which
I solved by going and making the _1 - _9 externs and defining them in my
own bind.cpp.  Could they be macros?  I actually wouldn't mind it if
they were boost::arg<1>() etc.  Normally when I use boost::bind I have
to write out the line broken up into parameters like so:
        = boost::bind(
                _1,
                some other parameter,
                a third parameter);
So it wouldn't matter that much.  But given that the documented form to
use is _1 etc I feel odd about using it against what is documented...

What about regarding bind's ability to get void-returning functions on
MSVC?  Is that being worked on?