Re: [boost] News about proposed Boost.Application library

Subject: Re: [boost] News about proposed Boost.Application library
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-07-29 05:43:37

On July 29, 2014 3:39:16 AM EDT, "Klaim - Joël Lamotte" <mjklaim_at_[hidden]> wrote:
>Sent from mobile.
>On 29 Jul 2014 02:33, "Rob Stewart" <robertstewart_at_[hidden]> wrote:
>>
>> On July 28, 2014 5:13:00 PM EDT, Antony Polukhin
><antoshkka_at_[hidden]>
>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)