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.