Boost logo

Boost :

From: Sven Van Echelpoel (sven.vanechelpoel.sv_at_[hidden])
Date: 2002-05-02 02:08:00

> Gennadiy Rozental wrote:

> You did not mention what is depp_cope_resource and scoped_resource, but I
> assume you have some where *the resource* class that latter branched using
> ownership policy into several specific resources types. Now let imagine you
> need to validate your HANDLE every time you accesing it. Of cource you
> could
> write free validation function and place it before *every* usage of your
> resource, but it does not sound very convinient. That is we need checking
> policy. So what we got at the end: You have storage policy ownership
> policy,
> convertion policy(you did not describe it) plus missing checking policy
> scattered all over your design. But all togerter they still mimic the same
> framework policy-base smart_ptr we discussing is providing. So I am making
> a
> conclusion that you need the same framework I do.

> Svenne.

> Gennadiy.

I 'm sorry, but you missed the point (which is probably my fault). All I
was trying to convey was that to me Loki::SmartPtr is a little
inconvenient for general resources and that whatever design is chosen
should make handling those resources as easy as SmartPtr handles free
store objects right now. For me this can be a separate type (e.g. the
smart_resource), which can use SmartPtr internally.

The convenience of what I'm using today is that I have to do very little
to create a new smart pointer for a particular resource (deriving from a
basic_resource_traits and implementing one or two functions). It can be
something as simple as this maybe:

 typename ResTraits,
 template<class> class OwnershipPolicy = ref_counted,
 class ConversionPolicy = disallow_conversion,
 template<class> class CheckingPolicy = assert_check,
 template<class> class StoragePolicy =
class smart_resource :
 public smart_ptr<ResTraits::handle_type, OwnershipPolicy,
                  ConversionPolicy, CheckingPolicy, StoragePolicy>

Or whatever. In the above example the library provided
resource_traits_forwarding_storage_policy simply forwards the
destruction of the resource to the traits class. Like I said before, I'm
a library user and as a user I like libraries that require the least
work to setup the functionality I need most. If one solution (SmartPtr)
cannot be made convenient enough for all situations it is supposed to
handle, then more solutions are required.


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