Boost logo

Boost :

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

"Eugene Lazutkin" <eugene_lazutkin_at_[hidden]> wrote:
>"John Madsen" <johnmadsen_usenet_at_[hidden]> wrote in message
>> I have little experience with X-Windows, so I can't comment on that.
>> 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
>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
>> management that doesn't have a suitable C++ wrapper for every case other
>> 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
>> act like pointers. If you want the pointer value itself from an auto_ptr,
>> call get(). Note also that std::string has c_str() rather than operator
>> 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
>> 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.


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