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

From: Jason Hise (chaos_at_[hidden])
Date: 2005-10-04 13:37:55

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'm not sure whether manual_creation should be a separate
>>  policy.
>>
>>Why not have the default policy have a constructor taking a raw
>>pointer, defaulted to a null pointer, plus provide a set() member
>>function?  You'd need to implement set() just as it is in
>>manual_creation now.
>>
>>   namespace boost { namespace pimpls {
>>      template <typename T>
>>      struct default_ : base<T>
>>      {
>>	 default_(T * pimpl_i = 0) : pimpl_(pimpl_i) { }
>>	 T & get() const { return *pimpl_; }
>>	 void set(T * pimpl_i) { delete pimpl_; pimpl_ = pimpl_i; }
>>      };
>>   } }
>>
>>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 
both of these functors create the instance if it does not exist, 
lazy_creation by having the constructor functor be a no-op and only 
operator-> creates the instance, and manual_creation by making both of 
these functors no-ops.  The type of factory to use is provided as a 
completely orthogonal policy which actually manages the semantics of 
creation and destruction (using new, malloc, an std_allocator, an in 
place aligned_storage buffer, etc.  Unfortunately I have not yet had 
time to look at the code for your library, so these ideas may or may not 
apply.

>>* 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 
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?

-Jason