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

From: Yitzhak Sapir (ysapir_at_[hidden])
Date: 2002-01-29 14:51:16

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

_Ns are defined in an unnamed namespace, so there should be no
conflicts; I
don't know why this happens in your case, perhaps you are using the same
source file in different static libraries and the compiler picks the
same
"unique" name for the unnamed namespace?

>  Could they be macros?

No. :-)
<--

The problem is not related to libraries as I first suspected (although
the linkage of the library is the first place it shows up), but rather
to precompiled headers.  This is the default for newly created projects
in MSVC usually.  It is not documented that bind cannot be used in
precompiled headers.  It is for this failure to compile that I asked
that they be macros.

Consider the following source files:
b1.h:
#include <boost/bind.hpp>
int f1();

b1.cpp:
#include "b1.h"
int f1()
{
_1;
return 2;
}

main.cpp:
#include "b1.h"

void main()
{
f1();
}

Now compile under MSVC as follows:
cl /I (boost directory location) /c /Fpb1.pch /Ycb1.h main.cpp
cl /I (boost directory location) /c /Fpb1.pch /Yub1.h b1.cpp
cl main.obj b1.obj

b1.obj : error LNK2005: "class boost::_bi::arg<1>  `anonymous
namespace'::_1" (?
_1@?%.\boost/bind.hpp2036319674@@3V?$arg@$00@_bi_at_boost@@A) already
defined in ma
in.obj
main.exe : fatal error LNK1169: one or more multiply defined symbols
found

-->
> 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
[...]
> Which defines ptr as const in respect to the class.  I'm not sure, but
> I'd guess this would help it optimize...

No, there is usually no need for "inline" here; it's implied in in-class
member functions, and in general what counts is whether the function is
visible to the compiler, not whether it has "inline" or not. With MSVC,
you
should try -Ob2 to let the compiler inline whatever it wants.
<--

I had sent you a much longer mail here.  The point was not that there
was a need for inline inside the in-class member functions.  The point
was that I'd be able to give the functions a compiler directive of
"__forceinline" if I wanted to.  MSVC 6 does rather poorly at inlining,
even when you specify maximum inline depth.  One of the oft cited
advantages of functors etc is that they inline well.  Under MSVC (I am
sorry I couldn't give you a more reasonable example than the rather poor
example I sent) they don't usually inline well because often MSVC
decides not to inline even if it can inline any function or if it is
given an inline definition.  But since MSVC gives you the ability to
declare a function __forceinline, you can bypass it, if you could
declare functions as __forceinline.