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. -- Best regards, Antony Polukhin