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

Subject: Re: [boost] News about proposed Boost.Application library
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2014-07-29 03:39:16

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:
> >2014-07-28 21:46 GMT+04:00 Renato Forti <rtforti_at_[hidden]>:
> >
> >* how about adding an additional template parameter to the get_symbol
> >method:
> >
> >template <typename ReturnType, typename T>
> >ReturnType* get_symbol(const symbol_type<T> &sb);
> >
> >Now ((pluginapi_create)sl("create_my_plugin")) will look slightly
> >better:
> >
> >sl.get_symbol<pluginapi_create>("create_my_plugin");
>
> +1
>
> >* 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.

>
> ___
> Rob
>
> (Sent from my portable computation engine)
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost