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 07:27:09

On Tue, Jul 29, 2014 at 12:19 PM, Joseph Van Riper <
fleeb.fantastique_at_[hidden]> wrote:

> On Tue, Jul 29, 2014 at 5:43 AM, Rob Stewart <robertstewart_at_[hidden]>
> wrote:
>
> > On July 29, 2014 3:39:16 AM EDT, "Klaim - Joël Lamotte" <
> mjklaim_at_[hidden]>
> > wrote:
> > >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 think there are two scenarios.  In one, you're dynamically loading the
> library, and you want it to remain in memory for the duration of the
> application's run (you never intend to deallocate it until the application
> is finished).  You might consider this scenario for situations where you're
> licensing different facets of your application, and licensing determines
> available features.
>
> However, there's another scenario where you dynamically load the library,
> then deallocate it as soon as you're done with it (and where it is
> important to do so).  For those scenarios, this centralized system of
> keeping all loaded libraries alive is an unnecessary and unwanted burden.
>  You might consider this scenario in cases where you have a long-running
> service that you cannot lightly take down, but you want to be capable of
> making updates to features the service use.  At least on Windows, you
> cannot replace a DLL if it is loaded, so if it's only loaded when in use,
> you'd be able to swap out the library without stopping the service.
>
> I think both scenarios can be supported by having an object that acts as
> this centralized system which one may use if desired, while also having the
> current system.
>
> - Trey
>
>
Thanks this is exactly what I meant. I understand the first case
but when using dynamically loaded libraries/modules, I more often
endup in the second case (in particular when it's "plugins" of a tool or
game or simulation engine, that need to be activated and deactivated when
necessary).

In the first case, you indeed want to make sure that the necessary
libraries are always loaded.
However in the second, you really need to have a way to be notified when
calling something
from an unloaded library. In this case, you might just trigger an error, or
just do some logging
or something. In my own cases I would not test the access returned object,
because
I assume that that object must not be accessible anymore once the related
library is unloaded.
Therefore, I consider this case a bug and want the application to crash
early if that happen.
I was suggesting weak_ptr (wrapped inside something that looks like a
std::function<>)
so that the user decides if or not he wants to check if the library is
still loaded before using the function.
But personally I wouldn't.

I agree with Trey's conclusion.

> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>