[boost] Re: Proposed smart_handle library

From: John Madsen (johnmadsen_usenet_at_[hidden])
Date: 2003-07-21 23:03:03

"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> wrote:
>> I read all of the previous discussion of this on the boost list and did
>not
>> find any good arguments against mine.
>
>> 1)  Pointer specific features have been removed for smart_handle.  Both
>> implicit and explicit type coercion features are gone as are operators *
>and ->.
>I do not see anything wrong with operator* and operator->. How are you going
>to provide an access to the handle value? operator* as good as anything else
>for this purpose. How are you going to provide an access to methods that
>handle type may expose. operator-> as good (if not best) way to do so.
>

get() is used to access the handle value.  Handles don't expose any methods so 
operator-> is a non-starter.  operator* could be used to access the handle 
value, but I don't see what the advantage to that is.

>> 2)  Rather than taking the handle type as a template parameter,
>smart_handle
>> classes take a handle policy (or traits class or description class or
>whatever
>> the correct term is).
>
>PBSP could do  the same.
>
>> (2) is designed to deal with the fact that the actual type of a handle
>rarely
>> uniquely identifies the handle type
>
>PBSP could do the same.
>
>> - Not all handles are pointers (e.g., file descriptors) and thus cannot be
>used
>> with smart_ptrs
>
>PBSP would cover everything.
>

I should say that many of these arguments I was making was against using the 
existing Boost smart_ptr classes for handle management.  I agree that a policy 
based smart pointer could be designed that would do all of the things you say, 
but I'll give reasons below why I don't think that's a good idea.

>> - Semantically, handles simply aren't pointers.  E.g, the pointer
>deference
>> operators make no sense for handles.
>
>Again it's your point of view. I have different. and PBSP could prohibit
>usage of operator* if you like so.
>

This may be something that we will never agree on, but I'll try to give fuller 
reasons for my point of view.  First, here is what I see as the similariies 
between handles and pointers.  In some, but not all, cases in C++, pointers 
serve as handles to a key resource -- namely, memory.  Operator new is the 
resource acquisition function and operator delete is the release function.  The 
difference is that pointers are a language construct while other handles (e.g., 
file descriptors, FILE*s, etc) are not.  The standard specifies detailed and 
often nuanced semantics for pointers and their interaction with the type 
system.  None of this applies to API based handles which serve only as chits or 
markers to be handed back to the API to identify the resource in question.

I suppose that where we differ is that you think the similarity is enough to 
justify unifying the management of both pointers and handles in a single 
component, whereas I don't.

[snip]

>
>I listed all you reasons. None seems to be sound enough to justify yet
>another component that mimics "smart pointer" concept. Whatever you do you
>will end up with either limited functionality or slightly cut version of
>PBSP (IMHO). That is why I stick with the my PBSP and use it for all my
>"smart pointer" needs.
>

I can only repeat that pointers are not handles.  You seem to be describing a 
policy based resource management class.  I think this is too broad.  I agree 
that the smart handle classes I've proposed have limited functionality.  That's 
the idea.  I also think that's what makes them worthwhile.

John