Boost logo

Boost :

Subject: [boost] Fwd: [Boost-users] Boost.DLL formal review is ongoing
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2015-07-04 05:39:58

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 +

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at