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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-01-30 06:00:22

From: "Yitzhak Sapir" <ysapir_at_[hidden]>
> 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.

Yes, I see your point now. Thanks.

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

Yes, I understand. But I don't like the suggestion... mostly because this
(adding __forceinline in third-party libraries) is not the way I optimize
code. I ignore the "inline problem" until it's time to profile, and then, if
a std::algorithm(..., bind()) line shows up, I simply rewrite the containing
function as a whole.

The good thing about this approach is that it can be applied to the standard
library (and other read-only libraries) as well, and it's more portable.