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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-10-04 14:12:32

From: Jason Hise <chaos_at_[hidden]>
> Asger Mangaard wrote:
> 
> >>* Why is "PimplType" not just "T?"
> >>
> >Corrected.
> >
> Why was this considered a problem in the first place?  Aren't more 
> descriptive names generally better?  The tendency to use single letters 
> for template parameters seems flawed to me.

I didn't consider it a problem.  I was questioning the value of
the longer name.  If there is only one parameterizing type for a
template, the ubiquitous "T" is well suited.  If there is a
concept the type must fulfill, then naming it according to the
concept is worthwhile.  If there are many parameterizing types,
longer names can make it easier to distinguish among the types.

In this case, the whole purpose of the class template is to wrap
one type which fulfills no concept definition, so "T" is
perfectly suited.  The benefit is more readable code.

> >>Thus, default_ does what your base and manual_creation policies
> >>do in one simple policy.
> >
> >But then you remove the default creation which is one of the advantages of
> >the library.
> >
> Wow, this definitely sounds like it mirrors some of my singleton work.  
> If it interests you, the way I currently handle automatic creation as a 
> policy is by having it define functors which are invoked by the smart 
> pointer constructor and operator ->().  The functors take a pointer to a 
> factory as the only parameter.  You can get greedy_creation by making 

Singletons have to come into being at relatively arbitrary times
and be accessible to many clients.  Pimpls are used in highly
restricted contexts.  The approach you're using for Singletons
seems like overkill.  For Pimpls, it's a simple matter of
initializing in a constructor or assigning in some member
function.  After that, it's all managed for you.

> >>* pimpl's member functions should be inlined.
> >>
> >>They are all trivial, so you should make them inline.
> >>
> >Aren't templates always inlined?
> >
> Agreed, and besides, isn't it usually better to let the compiler decide 

Does that mean you think they are always inlined?

> Agreed, and besides, isn't it usually better to let the compiler decide 
> what to inline or not inline on its own unless extensive profiling shows 
> that adding the inline keyword really gives you a big performance gain?

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?

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