Boost logo

Boost :

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2002-04-30 11:34:05


"Sven Van Echelpoel" <sven.vanechelpoel.sv_at_[hidden]> wrote in
message news:3CCE56BD.ED9D64EB_at_belgium.agfa.com...
> beware: lengthy post :-)
>
> [...]
>
> Looking at the above typedefs there seems to be little difference
> between smart_ptr and smart_resource. I'm a bit worried about the
> proliferation of types when using smart_ptr to handle common resources.
> Especially if you take the required interfaces of storage_policy and
> ownership_policy into account, which you'd have to code separately (I
> mentioned in my earlier post that is probably would be possible to
> create some sort of "generic" policies that simply forward the resource
> destruction and/or cloning/copying to the relevant API functions, which
> would lessen the workload).
>
> I must confess that my objection to Loki::SmartPtr is somewhat
> theoretical, since I cannot use it one the compiler we use (MSVC6,SP5).

I am using policy-based smart_ptr on much older compiler

> Noticing that the two most variable pieces of functionality are the
> destruction and the cloning/copying of the resource I factored these out
> into a traits class. Even so most of the boilerplate code fits into a
> basic_resource_traits class. This is more or less its definition (some
> types and operator<<(ostream&) were omitted for brevity):

As I outline in other post I can't use traits to model behavior that is type
inderpendent. But what you describing here is not a traits it is policy
cause you are passing it as a template arument.

>
> template<typename T, T DEF>
> struct basic_resource_traits
> {
> typedef T HandleType;
> typedef T ConstHandleType;
> typedef T* PointerType;
>
> // The default value of the resource 'handle'
> static HandleType NullValue;
> // Swaps two resource handles
> static void swap( ReferenceType l, ReferenceType r )
> {
> std::swap( l, r );
> }
>
> };
>
> template<typename T, T DEF>
> BasicResourceTraits<T,DEF>::HandleType
> BasicResourceTraits<T,DEF>::NullValue = DEF;
>
>
> For any resource, I simply derive my traits class from
> basic_resource_traits. Here's an example for HANDLE (used in a lot of
> APIs):
>
> // Most of the HANDLEs c
> struct WinHandleTraits :
> public basic_resource_traits<HANDLE,NULL>
> {
> // Destroys the handle
> static void destroy( HANDLE handle )
> {
> ::CloseHandle( handle );
> }
> // Clones the handle
> static HANDLE clone( HANDLE handle )
> {
> HANDLE currentProcess = ::GetCurrentProcess(); // never close
> // this HANDLE
> HANDLE dup = NULL;
>
> if ( FALSE == ::DuplicateHandle( currentProcess, handle,
> currentProcess, &dup, 0, FALSE, DUPLICATE_SAME_ACCESS ) )
> {
> throw ResourceError( "Cannot duplicate HANDLE" );
> }
>
> return ( dup );
> }
> };
>
> And the corresponding typedef:
>
> typedef deep_copy_resource<WinHandleTraits,AllowConversionPolicy>
> StdHandle;

>
> similarly I have a EventHandleTraits, defined like this:
>
> struct EventHandleTraits :
> public basic_resource_traits<HANDLE,NULL>
> {
> // Destroys the handle
> static void destroy( HANDLE handle )
> {
> ::DeregisterEventSource(handle);
> }
> };
>
> and the corresponding typedef:
>
> typedef scoped_resource<EventHandleTraits,AllowConversionPolicy>
> EvLogHandle;
>

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk