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-30 06:57:54

On Wed, Jul 30, 2014 at 12:20 PM, Andrey Semashev <andrey.semashev_at_[hidden]
> 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.