From: John Madsen (johnmadsen_usenet_at_[hidden])
Date: 2003-07-18 16:21:10
"Eugene Lazutkin" <eugene.lazutkin_at_[hidden]> wrote:
>I have a few comments in no particular order.
>1) I cannot imaging someone programming in C++ and using "FILE*s,and file
>descriptors" instead of iostream & Co. You've must be talking about
>incomplete systems like embedded systems, which don't have complete standard
>C++ library. Are there any real life examples for that? How frequent are
That's quite right. I don't see much use in having a wrapper for FILE*. File
descriptors' are a different story. Two cases that jump to mind are memory
mapped files and socket descriptors. In neither case are there general purpose
cross platform C++ libraries (that I'm aware of) that eliminate any reasonable
need to deal with file descriptors for these purposes.
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).
>2) Windows handles are problem indeed because they are not covered by
>standard libraries. MFC covers it but being a behemoth it is not suitable
>for some applications. ATL is better but it doesn't address handle issue. A
>lot of people and their grandma have created their own home-brewed handle
Yes, one of purposes is to make this easier and to provide a semi-standard
>2a) You are not entirely correct in assumption that "Most Windows' handles
>are actually void pointers". For years Microsoft uses so called "strict
>definitions" by default (you have to switch to old mode explicitly). This is
>relevant code from their headers for illustration purposes:
>As you can see HANDLE is void* but almost all other handles declared using
>DECLARE_HANDLE() macro, which makes them of different types. Notable
>exception is HGDIOBJ, which is void* as well. The former was done to
>facilitate inheritance-like relationship between generic GDI handle
>(HGDIOBJ) and specialized GDI handles (HPEN, HBRUSH, HFONT, HRGN, and so on)
>with C compiler.
I was unaware that this was now the default. However, the importance of the
RAII aspects of smart_handle still stand.
>2b) It appears to me that Windows handles and their profound importance are
>quite unique. I never struggled with something like that on X Window, for
>example. If this is the case, we are talking about platform-specific
>solution. I am not sure Boost is right place for platform-specific
>libraries. Of course, it is possible to make such library
>platform-independent but is it going to be used outside of Windows world?
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
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
>3) Necessity to call get() method every time you need to use handle is
>cumbersome. That's why auto_ptr or any other smart pointers define
>operator->() and operator*(). Instead of these operators smart_handle should
>define operator Handle() (where Handle is underlying handle type).
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
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
>4) Sometimes destruction of handles is more than a simple call to
>one-argument procedure. Real example from Windows, which is encountered
>HDC hDC = GetDC(hWindow);
>// do some drawing...
>ReleaseDC( hWindow, hDC );
>In this example destruction (releasing) involves some kind of context
>(window handle). Apparently it is not handled by proposed library.
Thanks for this example. I had not considered cases like this and will think
more about it.
>5) While I frequently needed scoped handles, I never encountered real need
>to have "weak" handles and reference-counted handles. When I wanted to do
>something like that, I created object, which was handled by smart pointer of
>some kind. Admittedly this is not light weight solution but it was never a
>bottleneck in my projects. Scoped handles are used extensively a should be
>as light weight as possible.
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.
>PS: Yeah, I am one of those poor guys, who wrote Windows handle wrappers for
>themselves. If you want to take a look, I can send you a file.
I'd love to look at whatever you've got. You can send it to the no spam email
below if you'd like.
Thanks for your comments,
john at illura dot com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk