Boost logo

Boost :

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,
> I solved by going and making the _1 - _9 externs and defining them in
> 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
"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:
#include <boost/bind.hpp>
int f1();

#include "b1.h"
int f1()
return 2;

#include "b1.h"

void main()

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
main.exe : fatal error LNK1169: one or more multiply defined symbols

> 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
> the top of the headers define the macro as either
> #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,
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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at