Boost.DLL formal review is ongoing
The formal review of Boost.DLL library by Antony Polukhin is nearing the end of the first week. As of today, over 100 people read through the library's tutorial, suggesting quite some interest. However, no reviews were submitted yet. Please take the time to post your thoughts - even if you don't have time to do a full review, or try the library, comments on design and interfaces are still very valuable. The summary of the library features and review checklists are reproduced below. Boost.DLL is a C++98 library for comfortable work with DLL and DSO. Library provides a portable across platforms way to: - load libraries at runtime - import and export any native functions and variables - make alias names for C++ mangled functions and symbols - query libraries/objects and executables for sections and exported symbols - self loading and self querying - getting program and module location by exported symbol The documentation can be found at: http://apolukhin.github.io/Boost.DLL/index.html and the source can be obtained at: https://github.com/apolukhin/Boost.DLL Please post your reviews on the mailing list and if possible, answer the following questions: - Should the library be accepted? - How useful is it? - What's your evaluation of - Design - Implementation - Documentations - Tests - How much effort did you put into your evaluation? - Did you attempt to use the library? On what systems and compilers? Thanks, Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, Jul 3, 2015 at 10:50 AM, Vladimir Prus <vladimir.prus@gmail.com> wrote:
The formal review of Boost.DLL library by Antony Polukhin is nearing the end of the first week. As of today, over 100 people read through the library's tutorial, suggesting quite some interest. However, no reviews were submitted yet. Please take the time to post your thoughts - even if you don't have time to do a full review, or try the library, comments on design and interfaces are still very valuable.
Vladimir, I planed a review for the library this weekend. I've been looking at it since it was still part of Boost.Application. Hope to get it done by Sunday evening. Regards, Rodrigo Madera
On 3 July 2015 at 15:50, Vladimir Prus <vladimir.prus@gmail.com> wrote:
The formal review of Boost.DLL library by Antony Polukhin is nearing the end of the first week. As of today, over 100 people read through the library's tutorial, suggesting quite some interest. However, no reviews were submitted yet. Please take the time to post your thoughts - even if you don't have time to do a full review, or try the library, comments on design and interfaces are still very valuable.
I started an experimentation to check a few things related to plugin systems specific to my projects and want to finish it before giving a final review. I still can do a pre-review using my experience so far, but wait for my confirmation before counting my review.
Please post your reviews on the mailing list and if possible, answer the following questions:
- Should the library be accepted?
YES, it should be accepted.
- How useful is it?
- It helps solving a common problem (the code managing plugins in an application). - It does it without the usual constraints (interface only in C for example) - this part I am actually challenging with my test code. - It's header only and cross platform. - It does not do more than helping getting functions and objects from shared libraries (like previous boost.extend did IIRC). - I tried to use several other such libraries before and so far it's the less intrusive.
- 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? - Implementation
I didn't look at the implementation yet.
- Documentations
It's good. I pointed a few things but globally it's working for me. Note: http://apolukhin.github.io/Boost.DLL/boost/dll/symbol_location.html I do not understand how to use this function, what is T here? Also, I did a lot of different plugin systems in the past so I am not sure what someone unexposed to this kind of system would think of the code. I suspect that the table in the QuickStart page might scare such people at first, but in the same time I find it very useful as a summary of how to use the library. I didn't have any problem with the tutorial so far.
- Tests
I didn't run nor read the tests provided with the library.
- How much effort did you put into your evaluation?
I read all the doc without references pages, a big part of references pages. The small test project I am trying to setup is a complex "worse case" plugin system matching my most difficult project (for which plugins are a vital part of the design), so once I do that I'll have a good idea of potential issues in non trivial cases.
- Did you attempt to use the library? On what systems and compilers?
Yes as said before I have a small test on-going but it's not finished yet. My attempt is currently on VS2013 64bit on Windows 7 and 8.1. I would like to try it with VS2015RC but Boost 1.58 does not compile correctly with this compiler. I will try it with gcc and clang on linux once my test is finished and working on Windows. I expect all the platforms to behave the same in my test, so we'll see.
On 7/4/2015 12:16 AM, Klaim - Joël Lamotte wrote:
Also, I did a lot of different plugin systems in the past so I am not sure what someone unexposed to this kind of system would think of the code. I suspect that the table in the QuickStart page might scare such people at first, but in the same time I find it very useful as a summary of how to use the library. I didn't have any problem with the tutorial so far.
FWIW, I found that table to be somewhat confusing as well. When looking at the table for the first time, it sounded as if importing/exporting C++03 and C++11 function is somehow different, but: - For exporting, the examples are the same except for C++11 one using rvalue type for parameter. - Likewise, the difference between importing C++11 function and C++ function appears to be the use of 'auto' - So, I conclude that in reality, these are identical, and mentioning them as separately rows in the table is just confusing. Maybe they should be collapsed, with two different alternatives specified for importing part? Thanks, Volodya
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
On 4 July 2015 at 11:38, Antony Polukhin <antoshkka@gmail.com> wrote:
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.
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.
2015-07-04 0:16 GMT+03:00 Klaim - Joël Lamotte <mjklaim@gmail.com>:
Note: http://apolukhin.github.io/Boost.DLL/boost/dll/symbol_location.html
I do not understand how to use this function, what is T here?
T could be any variable or function that you're interested in: int var; void foo() {} int main() { dll::symbol_location(var); // returns program location dll::symbol_location(foo); // returns program location dll::symbol_location(std::cerr); // probably returns location of libstdc++ dll::symbol_location(std::placeholders::_1); // probably returns location of libstdc++ dll::symbol_location(errno); // probably returns location of libc } I'll clarify the docs, thanks for the note! -- Best regards, Antony Polukhin
My review: First off, thank you to Renato and Antony for putting up the work necessary to develop this helpful library. It's one of those functionalities one can't believe isn't yet available in Boost. - Should the library be accepted? Yes, but once full support for OS X is also made available (which is almost done), and well as other platforms required for Boost acceptance. They should all be tested and supported with maintenance. - How useful is it? It's really helpful. Shared libraries are ubiquitous, and so they are taken for granted most of the time. Using them without linker help requires manual and error prone code that is so many times written over and over again. If the code should be portable, then it gets even worse. This library creates a simple abstraction that takes care of this otherwise messy code, making portable shared library usage simple. - What's your evaluation of - Design Simple and direct. Unobtrusive. I don't like the default section name "boostdll" on aliases... but that's just me, I guess. If a default is *really* needed, then ok. Also, as commented already, there is little type safety. It would be good to address this is a future version of the library, if at all possible, of course, using new techniques that might be available in the future, as I read previously on this thread. - Implementation The code looks clean and simple as well. As mentioned by Niall, it should be made to depend on other Boost libraries only when a standard is not available. Not because I don't think libraries should depend on one another (after all, libraries are there to help), but rather to use the standard if one is available. - Documentations Unfortunately, I'm not as happy with the documentation. Let me explain... I'm not a fan of calling a dynamic shared library a plugin. A plugin is implemented by means of shared libraries. But that's about it. The documentation uses the "plugin" word far too often. It could get misleading. The center of attention should be on using shared libraries, be them plugins or not. I believe the tutorial should give usage samples right away on consuming some system functions (some popular lib on POSIX, some Win32 functions on Windows). I see that there is a sample on the tutorials, but at the end, as the very last example. Some examples illustrating the nice abstraction between, for instance, LGPL libraries and consumer code would be great. I understand that the tutorial is from the older library that was plugin-centered, but the name, Boost.DLL, should reflect that it is for shared libraries, whatever the nature of them. For me, the current tutorial should be renamed "How to create a plugin manager using Boost.DLL", and another completely different tutorial focusing on shared libraries should be born. For me, the "plugin" word should just be eliminated from the documentation. If there would be a subsequent library called Boost.Plugin with all the features a plugin management system needs (like lots of metadata and predefined interfaces), then the plugin word should appear again. Other minor points: * Could be more clear that this is a header-only library. * Code that is portable needs ifdefs for both POSIX and Windows systems. Boost.DLL can solve this quite well, and some examples for this motivation would be good to get people even more energized to give the library a try. * It would help to have a link in dll::import and dll::import_alias to what an "alias" is. It was confusing to me until I realised what the documentation was referring to as a Boost.DLL alias. - Tests The code looks good and tests a variety of scenarios. I didn't check, however, if all the functionality is tested. Reminding that this part of the library should also be updated to make it work on OS X and other OSes that might be required (FreeBSD, as well?). As I mentioned in earlier emails, I couldn't get the tests to work on OS X. Antony is already working on this and looks close to finishing it. - How much effort did you put into your evaluation? About a couple hours per day for almost a week, now. - Did you attempt to use the library? On what systems and compilers? Yes, successfully on Windows. * OS X Yosemite (10.10.3) with Clang: Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix * Windows 8.1: MSVC 2013 Best regards, Rodrigo Madera
On Fri, Jul 3, 2015 at 9:50 AM, Vladimir Prus <vladimir.prus@gmail.com> wrote:
The formal review of Boost.DLL library by Antony Polukhin is nearing the end of the first week.
Looks very interesting! An enumeration of platform support would be useful. Some grammar in the documentation could be improved. Cheers! Andrew Hundt
participants (3)
-
Andrew Hundt -
Antony Polukhin -
Klaim - Joël Lamotte -
Rodrigo Madera -
Vladimir Prus