Boost logo

Boost :

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


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

smart_ptr::smart_ptr( smart_ptr const& ptr )
: StoragePolicy( ptr ), OwnershipPolicy( ptr ),
  ConversionPolicy( ptr ), CheckingPolicy( ptr )
   if( OwnershipPolicy::add_reference( StoragePolicy::storage() ) )

Note following:
1. StoragePolicy IS responsible now for pointee copying (unlike Loki
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
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.

Let me know what you think,


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.

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