2015-07-04 0:16 GMT+03:00 Klaim - Joël Lamotte <mjklaim@gmail.com>:

On 3 July 2015 at 15:50, Vladimir Prus <vladimir.prus@gmail.com> 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.