10

I have many LoadLibrary in my project, and need to call FreeLibrary manually for each LoadLibrary. I want to use the std::unique_ptr with specific deleter to make it auto release my dll resource.

This is what I am trying to define:

std::unique_ptr<HMODULE, BOOL(*)(HMODULE)> theDll(LoadLibrary("My.dll"), FreeLibrary);

But the compiler complains the type does not match. I found out it expects *HMODULE from LoadLibrary. That is std::unique_ptr<A> will expect A* as its pointer type. It looks I still need to define a new class to manage DLL resource(LoadLibrary in constructor and FreeLibrary in destructor).

Is is possible to make std::unique_ptr<A> to just expect the A as its pointer type?

Updated,

The following is pros and cons for new class and using std::unique_ptr, summarized from the answers.

Create another dll management class,

pros:

  • Fully controllable to customize for DLL semantic.
  • Isolate the DLL related parts into a class with one responsibility.
  • Easy to extend if need more functionality for DLL like exposing symbol.

cons:

  • Need rebuild the RAII part what stadard auto pointer has been done.
  • Has chance to make mistake in RAII part.
  • Need Declare a new class.

Use std::unique_ptr with custom deleter,

pros:

  • No need to declare another a class.
  • Reuse the RAII part of unique_ptr.
  • Maybe the move semantics prevents DLL Module instance to be copied?

cons:

  • The Dll resource semantic may not fit the standard auto pointer, and error-prone?
  • The template parameter in unique_ptr is complex and hard to find where error is.
  • HMODULE is void*, a type-less type, may be a problem to integrate with unique_ptr?

Please correct me at comment if I am wrong.

Chen OT
  • 3,486
  • 2
  • 24
  • 46
  • 2
    to be honest I think wrapping the DLL in a class is a bit more safe because of the error handling even though it initially make look elegant using unique_ptr – AndersK Jul 29 '15 at 07:56
  • @CyberSpock Fully agreed. – Mateusz Grzejek Jul 29 '15 at 07:58
  • So far I found that, I can test the whether `theDll.get()` is null or not to know `Is LoadLibrary is succeeded?`. By http://stackoverflow.com/a/11164463/2210478, if the `theDll.get()` is null, the `std::unique_ptr` will not call deleter on pointer. So I don't worry I pass a NULL into FreeLibrary. – Chen OT Jul 30 '15 at 05:19
  • My question may be possible duplicate: http://stackoverflow.com/questions/12184779/using-stdunique-ptr-for-windows-handles – Chen OT Jul 30 '15 at 05:22
  • ATL provides a HANDLE manage class, CHandle. https://msdn.microsoft.com/en-us/library/5fc6ft2t.aspx#chandle__chandle – Chen OT Mar 05 '18 at 16:43

4 Answers4

9

According to this page, HMODULE is HINSTANCE, HINSTANCE is HANDLE, HANDLE is PVOID, and PVOID is void *. Which means that HMODULE is a pointer type. So the following should work:

std::unique_ptr<std::remove_pointer_t<HMODULE>, BOOL(*)(HMODULE)> theDll(LoadLibrary("My.dll"), FreeLibrary);
Nikolai
  • 3,053
  • 3
  • 24
  • 33
6

You need to provide a corresponding ::pointer type for unique_ptr, if you use it to manage a resource T which is not referred to by T*. Here T is the first template argument of unique_ptr.

If no ::pointer type is not defined, T* is used. In your case, it's HMODULE* which is wrong.

struct tLibraryDeleter
{
  typedef HMODULE pointer;
  void operator()(HMODULE h) { FreeLibrary(h); }
};

std::unique_ptr<HMODULE, tLibraryDeleter>(::LoadLibraryA("My.dll"));

Check out here and here.

Community
  • 1
  • 1
Eric Z
  • 14,327
  • 7
  • 45
  • 69
  • Yes, this should work. But few more lines of code and you have nice, simple wrapper class instead of weird and error-prone custom deleters for `DLL`s, which is simple not the right thing to do. – Mateusz Grzejek Jul 29 '15 at 08:08
  • 4
    I suggest you rethink what you're saying. I have no idea why and how you consider this well-defined custom deleter as `weird and error-prone`. If you really think this, at least show us how it can go wrong. If you have any concern, take a look at [here](http://en.cppreference.com/w/cpp/memory/unique_ptr), and [here](http://stackoverflow.com/questions/12184779/using-stdunique-ptr-for-windows-handles). The fact is you're reinventing the wheels which is error-prone. – Eric Z Jul 29 '15 at 09:01
  • @MateuszGrzejek Why is the custom deleter error-prone? Is it just a description to tell unique_ptr what release function it should call when it is deleting? – Chen OT Jul 29 '15 at 11:02
  • This answer is what I am looking for. It looks it is the std way to describe the different pointer type for custom type, HMODULE instead *HMODULE, to integrate with std::unique_ptr. – Chen OT Jul 30 '15 at 05:10
  • @Chen Sure. Please keep in mind that if you need a cross-platform library handler or you want more custom behaviors(e.g., do something before the unload), a custom RAII class is your best choice. – Eric Z Jul 30 '15 at 05:34
  • 1
    Yeah, currently I just only need the auto release functionality for my dll resource on Windows platform. If I decide to extend more functionality for dll or makes the it more general, I will consider to move it into a dedicated class. Thanks. – Chen OT Jul 30 '15 at 05:39
  • @MateuszGrzejek, actually, NOT reusing the functionality provided by the standard library is more error-prone. Smart pointers are not so easy to write, if you forget to disallow copying, for example your application will crash. A custom deleter gives you all this for free and you can also use it for std::shared_ptr if you need it later. – Levi Haskell Dec 21 '15 at 20:54
1

Please, look at unique_hmodule in Windows Implementation Libraries (WIL)

One may use it as is or just borrow implementation.

ivan_onys
  • 2,282
  • 17
  • 21
0

It looks I still need to define a new class to manage DLL resource

Why do you think it is a bad idea?

Why not this way?

class DynamicLibrary
{
protected:
    HANDLE      _handle;
    string      _path;

public:
    DynamicLibrary();
    DynamicLibrary(const string& path, bool autoLoad = false); // if(autoLoad) this->Load()

    ~DynamicLibrary(); // if(this->IsLoaded()) this->Unload()

    Result Load(); // LoadLibrary() here
    void Unload(); //FreeLibrary() here

    bool IsLoaded() const; // return this->_handle != nullptr
};

Then, you can even extend this class to make symbols retrieving cleaner:

class DynamicLibrary
{
    //cut

    void* RetrieveSymbol(const char* symName) const;

    template <class Cast_type>
    Cast_type RetrieveSymbolAs(const char* symName) const;
};

Example:

DynamicLibrary lib("XXX.dll", true);
assert( lib.IsLoaded() );

FuncType dll_func = lib.RetrieveSymbolAs<FuncType>("dll_func_name");

Explicit type designed to represent DLL instance is much better, I think. Then, you can store array of such objects and all goes automatically. Clean, simple, easy to implement.

Storing list/array of std::unique_ptr<HANDLE, Some_custom_unloader> seems to me like a bad design.

Mateusz Grzejek
  • 11,698
  • 3
  • 32
  • 49
  • 1
    The std::unique_ptr has implemented the delete-on-destruct, so I think why not just reuse its code and just pass the custom deleter. To define a typedef to hide its complex declaration may be less effort to create a explict type class. – Chen OT Jul 29 '15 at 07:18
  • You're avoiding typing but increasing error possibility and reducing code clarity by hiding very important and specific problem in strange constructs instead of simple, easy-to-maintain, customizable class with single responsibility But it's your code - your choice. – Mateusz Grzejek Jul 29 '15 at 07:22
  • 1
    although not answering his question I think this is the better way +1 – AndersK Jul 29 '15 at 08:00
  • 3
    I don't see how writing your own class is less error prone than using a standard feature. – Nikolai Jul 29 '15 at 08:42
  • @Nikolai There is no such thing like "standard feature" for handling DLLs in C++. Error handling, symbols loading - do you really want this code to be spread out somewhere? Class means encapsulation. DLL handling is the perfect candidate for this. – Mateusz Grzejek Jul 29 '15 at 08:45
  • 2
    @MateuszGrzejek OP didn't ask for error handling or symbol loading. unique_ptr is a standard feature and it works perfectly for OP's use case. – Nikolai Jul 29 '15 at 08:49
  • This solution may work for him better and it's his choice whether he goes for it or not. If he doesn't like it, he will simply not use my solution. It's not your task to decide what did he ask for and what he didn't. – Mateusz Grzejek Jul 29 '15 at 08:55
  • -1: I don't recommend this code. It asks OP to rewrite something that already exists. Moreover, this is error-prone. E.g., is there supposed to be an inheritance hierarchy? Why members are protected? Do you want to prevent the copying? As you don't want a library to be unloaded twice right? etc. The point is, the more code you write, the more mistakes you're likely to make. – Eric Z Jul 29 '15 at 09:11
  • `is there supposed to be an inheritance hierarchy? Why members are protected? Do you want to prevent the copying?` So, the solution is wrong because it requires thinking, giving you in return well-defined semantics for DLL handling? Let's end this discussion, it's pointless. – Mateusz Grzejek Jul 29 '15 at 09:26
  • I personally prefer a dedicated class, but the execution is flawed. E.g. as Eric Z mentioned, the copy c'tor is not suppressed, which can easily result in a double free. That's UB, not "well-defined semantics". In addition to the above criticism, the two argument constructor should be explicit. IMO, the data members should be private and the class final. It should be given move semantics as well. – Arne Vogel Jul 29 '15 at 12:56
  • One advantage of an independent class is that it can have the same interface but different implementations for different operating systems. – Walter Jul 29 '15 at 16:32
  • Maybe this question http://stackoverflow.com/questions/14878121/is-there-a-proper-ownership-in-a-package-for-handles-available is one of possible issues that using unique_ptr to manage dll. – Chen OT Jul 30 '15 at 05:27