On 4 July 2015 at 11:38, Antony Polukhin wrote:

2015-07-04 0:16 GMT+03:00 Klaim - Joël Lamotte :

...

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

It's ok, the solution to write a shared library in the the filesystem before loading it is what Ihave been doing so far and it works well. I was just wondering if it was possible with memory. :) If the plugin is in an archive file, I have to extract it in a temporary directory before loading it, which is what I would like to avoid, but it seems unavoidable.

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.

I don't write an interpreter (I'm really just managing plugins) but I didn't know that, it seems useful in some other contexts. Thanks for the pointer.