Re: [boost] Please look at my suggested pimpl library in the file vault.

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-10-04 16:24:37

From: Jason Hise <chaos_at_[hidden]>
> Rob Stewart wrote:
> 
> >Many compilers don't do it at all unless you suggest it via
> >"inline" or put the code in the class definition.  Some will
> >inline things you didn't suggest should be.
> >
> >In this case, the functions are nothing but forwarding
> >functions.  Why would you want to pay for an extra function call
> >on those compilers that won't do anything unless you ask for it?
> >
> Based on reading item 25 in Herb Sutter's "Exceptional C++ Style", I was 
> under the impression that a decent compiler would easily inline calls 
> like this on its own, without any suggestions from the programmer.  But 
> then I haven't directly done any profiling myself to compare how 
> differently modern compilers behave when explicitly provided with the 
> inline keyword, so I could well just be under a mistaken impression.

Not all compilers/linkers do what Herb is talking about.  When
you are targeting your code to a single platform, you can find
that it is better to avoid inlining unless you've profiled.

If your function simply calls another function, then inlining is
harmless for those platforms that would inline it anyway, and
helpful for those that wouldn't.  Thus, in writing a library, you
can reasonably inline the simplest of functions (provided you
know about the hidden aspects that may be lurking behind the
trivial source code).  The simplest way to confirm that inlining
is helpful is to write and profile test code with and without the
inline keyword.  That doesn't account for all uses of the code,
but it is reasonable.  (A Boost config macro indicating how well
a platform does at inlining could be used to control whether you
write inline or not.  When all is said and done, however, the
compiler can ignore your request to inline a function anyway.)

In the pimpl library case, the pimpl member functions I was
referring to were as simple as they get.  Now, taking another
look, I note that the policies inline some functions that
probably shouldn't be inlined.  As coded in the version of the
library I have, for example, base::get() is much too big to
assume inlining is a good idea (it constructs and throws an
exception if a condition is satisfied).  If you change
base::get() to simply return the dereferenced pointer, then it
should be inlined.  Then, pimpl::operator -() will be an inlined
call to base::get(), and base::get() will be inlined to nothing
more than a pointer dereference.  Thus, using a pimpl will be
just the same as using a raw pointer (when using the member
selection operator, at least).

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;