On July 29, 2014 3:39:16 AM EDT, "Klaim - Joël Lamotte"
Sent from mobile. On 29 Jul 2014 02:33, "Rob Stewart"
wrote: On July 28, 2014 5:13:00 PM EDT, Antony Polukhin
wrote: * what will happen with the application, if shred library goes out of scope but we continue to use symbols from it? Must it be prevented somehow by the Application library? Is it described in docs?
It would be nice if get_symbol returned a smart pointer that
contained a shared_ptr to the library. When all such references are released, the library can be unloaded.
I disagree. In my experience it would be more useful if it contained a weak_ptr to the library, with a centralised system keeping all loaded libraries alive and allowing the used to unload the library explicitely. The get_symbol return type would then be testable. That way it is easier to find issues related to plugins and its still possible for the user to prevent these issues at runtime.
Please explain. Using a weak_ptr means each access must be tested, with synchronized access, to boot, versus assurance of validity with the shared_ptr. I can see some value in being able to unload a library even with outstanding references, but I'm not certain the overhead is worthwhile. I'll grant that calling such functions is likely not in a critical path, but I'd like to understand your use case. I'm also not enamored implications of the "centralized system" you mentioned to track the open libraries. [snip my earlier signature block and the list's footer] Please trim all unneeded text from your replies. ___ Rob (Sent from my portable computation engine)