Handles have proper semantics other than pointers. So for me an example like this (extracted from the Rule of Zero):
class module {
public:
explicit module(std::wstring const& name)
: handle { ::LoadLibrary(name.c_str()), &::FreeLibrary } {}
// other module related functions go here
private:
using module_handle = std::unique_ptr<void, decltype(&::FreeLibrary)>;
module_handle handle;
};
using unique_ptr
as an 'ownership-in-a-package' for handles is a bad example. First, it makes use of internal knowledge that the handle is a pointer type, and use this to make a unique_ptr
to the basic type the "opaque" handle type builds upon.
Handles can be any type, they may be a pointer, they may be an index or who knows. Most importantly, what you have at hand (from most C API's for example) is a handle and its resource releasing function.
Is there a proper 'ownership-in-a-package' that works in handle semantics? I mean, already publicly available for one to use?
For me, unique_ptr
et. al. doesn't work, I must make unnecessary assumptions about what the handle type is, when what I want is just to get an 'ownership-in-a-package' through the opaque handle type and its releasing function, solely.
It doesn't make sense for one to peer inside the handle type to make constructions upon this information. It's a handle, it should not matter.
I'll quote here the feelings of another SO user in another question's answer:
Create a specific "smart pointer" class, won't take long. Don't abuse library classes. Handle semantics is quite different from that of a C++ pointer; for one thing, dereferencing a HANDLE makes no sense.
One more reason to use a custom smart handle class - NULL does not always mean an empty handle. Sometimes it's INVALID_HANDLE_VALUE, which is not the same.
Disclaimer:
This question reformulates and builds upon this one:
The type
unique_ptr
is less general than the phrase "handle", yes. But why shouldn't it be? Just one of your "handle" examples (say, the one that is an integer index), is precisely as general asunique_ptr
. You can't compare one specific kind of handle with "all handles ever".If you want a single, concrete C++ type (or type template) that is a handle without actually defining any specific handling semantics then... I can't help you. I don't think anyone tractibly could.
This is a toy example of "type disguising" I was having fun, that also has something to do with the discussion. I'll leave it here for reference (I'm not responsible for any harm caused by it!).
Test:
Output:
I would have had more fun if .(dot) could be overloaded =)
This is a rough sketch of the tool I ask, for the case of unique ownership. There's no need to peer inside the native/legacy handle type, no encapsulation violation, no ugly extra wrapping required. Works for almost all kinds of legacy handles, integral or pointer based.
It provides one extra feature, beyond resource management, which is impersonation of the raw handle, I find it somewhat useful.
This is some sample usage:
EDIT
It's surprising how people follow a similar scenario for such situations. This, for example, contains the same handle impersonation feature:
https://github.com/adobe/chromium/blob/master/base/win/scoped_handle.h
Glad I came to know in the
##c++
IRC channel about Generic Scope Guard and RAII Wrapper for the Standard Library.Current state of the proposal: