[boost] Re: Proposed smart_handle library

From: John Madsen (johnmadsen_usenet_at_[hidden])
Date: 2003-07-19 21:19:39

"Eugene Lazutkin" <eugene_lazutkin_at_[hidden]> wrote:
>Inline,
>
>"John Madsen" <johnmadsen_usenet_at_[hidden]> wrote in message
>news:bf9oc4$t0$1_at_main.gmane.org...
>> I have little experience with X-Windows, so I can't comment on that.
>However,
>> there is absolutely *nothing* in the smart_handle library that is platform
>> specific.  Just because one of the most obvious cases where it is useful
>is a
>> specific platform, does not make the library itself platform specific.  I
>find
>
>COM can be touted as platform independent standard but in 99.99% of case it
>is used on Windows. Looks very windowsy to me. ;-) We can have any
>proprietary stuff dressed as platform independent. In best case such
>masquerade would fool us into thinking that it is more than it is. In worst
>case it would be clumsy to use for proprietary stuff and unusable for
>anything else.
>

I fail to see how COM is a relevant analogy.  The smart_handle classes I've 
proposed will work on all major platforms unlike COM.  Several people have 
already suggested that it would be worthwhile for FILE*s and file descriptors.

>> it hard to believe that there is no other C API which uses handles for
>resource
>> management that doesn't have a suitable C++ wrapper for every case other
>than
>> Windows.
>
>Usually solution and problem go in pair. And problem goes before solution.
>In this case solution is our response to problem. Well, your comment tells
>me that we have a solution in search of a problem. Not that there's anything
>wrong with that.
>

See point above.

>> that auto_ptr and the like provide those operators so that they can
>actually
>> act like pointers.  If you want the pointer value itself from an auto_ptr,
>you
>> call get().  Note also that std::string has c_str() rather than operator
>const
>> char*().
>
>Using operator->() and operator*() you use "pointer value itself". It is
>pretty rare situation when you need it directly and not as part of
>abc->def() or *abc constructs. Example of c_str() is irrelevant --- you can
>do all string manipulations without c_str(). The former is needed to
>interface legacy systems, which is not frequent case.
>

Automatic conversions are well known sources of hard to find bugs.  Six 
characters hardly seems like a big deal.

>Auto_ptr was modeled after regular pointer. That is why it is so simple to
>use. It provides a) "invisible housekeeping" (see beginning of post) and b)
>has pointer-like "API". In most cases it can be used as drop-in replacement
>in existing code.
>
>I think smart handle should be done using exactly the same philosophy.
>"Invisible housekeeping" clause stands. And handle-like "API" is ...
>seamless conversion. What are real downsides of that?
>
>> I agree that in many cases scoped is more useful.  However, it was fairly
>> trivial to do shared and weak, so I figured why not?  Also, shared_handles
>will
>> work in stl containers while scoped_handles will not.
>
>Isn't it an overkill to use reference counting to put handles in vector? Is
>it the best solution for such problem? :-)
>

Not necessarily.  Please suggest another.

John