2014-07-30 14:57 GMT+04:00 Klaim - Joël Lamotte
On Wed, Jul 30, 2014 at 12:20 PM, Andrey Semashev < andrey.semashev@gmail.com
wrote:
I think you can achieve any behavior you described with the interface Peter suggested, can't you?
// p1 locks lib from being unloaded shared_ptr< foo > p1 = get_symbol< foo >(lib, "foo"); // p2 does not lock lib from being unloaded and is testable weak_ptr< foo > p2 = get_symbol< foo >(lib, "foo"); // p3 does not lock lib from being unloaded and crashes if used after lib is unloaded foo* p3 = get_symbol< foo >(lib, "foo").get();
Personally, I'd prefer get_symbol to return something immediately usable, i.e. shared_ptr. I'd also like to emphasize that it should return a pointer and not a function since the symbol may be data. Just my 2 cents.
I might have misunderstood what Peter suggested: I thought he suggested that get_symbol<> would return a smart pointer (not shared_ptr) that would _internally_ contain a shared_ptr to the plugin and the access to the data.
Returning a raw pointer is not user friendly. User will need to look
through the docs to determinate how to deal with pointer (must it be freed,
can we use that pointer after library unload).
How about returning a reference? This is intuitive interface that rises no
questions:
int *p;
{
shred_library lib("/usr/lib/myapp/plugins/plugin.so");
auto& f = lib.get_symbol