Need a hand with tech consulting? I can help!
Learn more about how we can work via black.af .

Using `shared_ptr` to manage `dlfcn.h`

Trying to wrangle with using shared_ptr in dlfcn.h.

:pencil: by Jacky Alciné Jacky Alciné :book: an development post :bookmark: development , c++ , libraries :clock7: written :eyeglasses: about 1 minute, 358 words :link: Comments - 0 Mention(s) - Permalink

In lieu of getting Wintermute’s library-esque approach working, I’ve been hammering the <tr1/memory> and <dlfcn.h> headers for about a week or so. It might be more, but in time I’ve spent in front of the terminal reading or just in the browser reading documentation and source code. The idea of std::shared_ptr is so freaking awesome, I used it a lot within Qt with QSharedPointer and the meta-object hierarchy it employs. But now, without that beautiful harness in an attempt to build something that’d be not only fast but easier to incorporate in other projects, the prerequisite learning curve just hit the sky.

The pain point I have currently with my code is here:

Focusing on line 11 of that snippet, it seems like setting nullptr to handlePtr. According to the documentation for std::shared_ptr::operator =(), the normal behavior seems to be destroying the original value and then setting the internal data’s reference to the new value. Which is okay. And I can live with that.

But here’s something fun. The class that’s used by std::shared_ptr here is a undefined struct; it’s the suggestion I got when asking in IRC in ##c++. If you have a better idea, it’d be lovely but for now; I managed to load the plugin and resolve functions from it. The only pain point right now (which kind of makes sense) is that it’s not able to delete the memory held by the shared_ptr. Good chance I’d update this post with my solution, but for now, I’m quite stumped. My progress is going to be marked on a pull request so feel free to comment there on suggestions. Cheers!