Boost logo

Boost :

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

Asger Mangaard wrote:

>>* Why is "PimplType" not just "T?"
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

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at