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]
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk