Re: [Boost-users] Boost.DLL formal review is ongoing

Subject: Re: [Boost-users] Boost.DLL formal review is ongoing
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2015-07-04 05:38:24

2015-07-04 0:16 GMT+03:00 Klaim - Joël Lamotte <mjklaim_at_[hidden]>:
>
>
> On 3 July 2015 at 15:50, Vladimir Prus <vladimir.prus_at_[hidden]> wrote:
>>
>> - What's your evaluation of
>>   - Design
>>
>
> I consider the solutions provided to solve each usual issue with plugin
> systems to be simple
> and clear, easy to use (as long as you understand what loading plugins
> imply).
>
> Until I check in some complex cases, I think the design is very good.
> The symbol name magic might be tricky to understand sometime but it's an
> issue which is a side effect of providing
> a simple tool to manage symbole names, so it's still good.
>
> One thing I was wondering: would it be possible to provide a way to load
> shared libraries from
> raw memory? Or does the OS APIs all requires that the library have to be
> on a file sytem?
>

Unfortunately, there's no portable way to load libraries from raw memory.
However you can always mount a filesystem that directly maps to memory (for
example Tmpfs on Linux) and store your data in there. This may look like a
big performance overhead, but actually loading a shared library takes much
time so you won't probably notice the overhead of additional create_file +
memcpy.

If you're planing this feature to write interpreters\JIT compillers and you
just need a place to store end execute generated native code, then
Boost.Interprocess's memory mapped files fill probably suit you better.
Shared libraries contain a lot of headers, helper data for load and a bunch
of other stuff that would be really hard to generate.

-- 
Best regards,
Antony Polukhin