Policy-based Smart Pointer: attempts t oresolve communication issues

From: rogeeff (rogeeff_at_[hidden])
Date: 2002-02-12 04:21:25

Hi

Recently I was working for my purposes on implementation of Loki 
style Policy-based smart pointer for SunPro 4.2 and MSVC compilers, 
while I was trying to avoid some of the issues of Loki SmartPtr, 
including communication ones. I have come to conclusion that Loki 
SmartPtr implementation mistreat a bit Storage and Ownership 
policies. As we sad Storage policy should answer on question HOW to 
store, access, copy and release the resource. While Ownership policy 
should answer on question WHEN to release the resource. Note that it 
should not manage WHEN or HOW to perform a resource copy, since first 
is managed by user (by means of calling copy constructor or 
assignment operation), and second by StoragePolicy. But then how come 
Loki implements DeepCopy as OwnershipPolicy?! "Deep copy" describes 
*how* to perform a copy, you know (the OwnershipPolicy for 
DeepCopyStoragePolicy I would name confident_owner means that such 
SmartPtr is always sure that resource belong to it and so could be 
destroyed with SmartPtr). Or why Loki DestructiveCopy policy 
implementation knows how to release old pointer? (it assumes that it 
is enough to assign default constructed value, but what if my storage 
policy has different default value?). All evidence leads to SmartPtr 
copy constructor. I changed it, so in my implementation it looks like 
this:

smart_ptr::smart_ptr( smart_ptr const& ptr )
: StoragePolicy( ptr ), OwnershipPolicy( ptr ),
  ConversionPolicy( ptr ), CheckingPolicy( ptr )
{
   if( OwnershipPolicy::add_reference( StoragePolicy::storage() ) )
     const_cast<smart_ptr&>(ptr).release();
}

Note following:
1. StoragePolicy IS responsible now for pointee copying (unlike Loki 
version)
2. QwnershipPolicy::add_reference returns boolean value that specify 
whether smart_ptr should release original pointer (to support 
destructive copy)
3. copy constructor accept always const smart_ptr (Loki propose trick 
to accept non-const  reference as constructor argument. But this 
would make any auto_ptr data member to be mutable. It is not obvious 
what is better). That is why const_cast is used to call non-const 
release().
4. add_reference is called on already copied local storage. ( Unlike 
Loki )

Significant part of OwnershipPolicy interface looks this way now:

bool        add_reference( stored_type& );      - add deference, 
returns true if original value should be released.
bool        release_reference( stored_type& ); - release reference, 
returns true if stored pointer should be released

While the significant part of Storage Policy looks like this:

StoragePolicy::StoragePolicy( stored_type const& ) performs real copy 
of pointee.

Now, since copying is performed by StoragePolicy there should not be 
a problems with implementing of smart_ptr for arrays.

I upload complete implementation and test module into vault 
area.Please, ignore some awkwardness of it , since it is supposed to 
work on old SunPro 4.2 witch does not have nor namespaces, nor 
template member function, nor explicit and so on. It is also 
incomplete, but I do not need rest to make my point. The code is 
compiled and tested under SunPro 4.2 and MSVC6SP5.

http://groups.yahoo.com/group/boost/files/PolicyBased%20smart_ptr/

Let me know what you think,

Gennadiy.

P.S. There is one issue (at least) that still is not covered: What if 
I want to extend SmartPtr interface with action that require access 
to both Storage and Ownership policies functionallity. Example: I 
want to add method void aquire() that will aquire for me resource 
from some resource storage (I do not want/need to know where from). 
Now the question is where to put the implemntation. I found that 
there are at least 2 ways to handle it:
1. External implementation: Inherit from regular (without custom 
method) smart_ptr and implement it in a child.
2. Virtual trick: a) add virtual reset( storage_type& ) = 0; to 
StoragePolicy; b) implement void acquire() as a public part of 
StoragePolicy interface using virtual reset. Though I do not know how 
portable it is.