Inline,
"John Madsen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> The main uses of the library as I see it is to handle two main cases:
>
> 1) Where a programmer needs to access an API (whether it be from the OS
or a
> 3rd party C API) which uses handle-based resource management and for which
not
> suitable C++ wrapper exists.
> 2) As an aid in implementing C++ wrapper classes for APIs mentioned in
(1).
It looks like reasonable goal. Personally I found that there are two cases:
1) If there is large existing API => use smart handles. In this case smart
handle serves two purposes:
a) provides invisible housekeeping (like destruction of underlying handle)
b) behaves like regular handle to be easily used with existing API
2) If existing API is compact => use functional wrapper. Smart handle may be
used as part of such wrapper.
Example for #1. Windows GDI has hundreds (if not thousands) API functions.
New versions of Windows introduce new API functions. It doesn't make any
sense to cover it with functional wrapper. MFC tried it and failed.
Example for #2. Synchronization primitives in Windows are represented by
handles as well. API is compact (~5 functions per primitive). Additional
problem is almost all synchronization primitives are represented by generic
HANDLE. In this case it makes sense to use functional wrapper instead of
smart handle.
> 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.
> 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.
> Six characters (".get()") doesn't seem cumbersome to me and seems much
better
> than a conversion operator which for many reasons is frowned upon. Note
also
It all depends on who you ask. Some people are 100% sure that multiple
inheritance == bad design in 100% cases. Some people hate virtual
inheritance. Some people think that OOP is sooo 60s. Some people think that
generic programming should be banned. I say: look at the problem and use
what is more appropriate.
> 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.
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? :-)
Thanks,
Eugene
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
