Boost.DLL formal review is ending soon - submit your reviews
Boosters, I wanted to remind that the formal review of Boost.DLL library by Antony Polukhin is nearing the end - the last day to submit reviews is Sunday. Of course, not much discussion is likely to happen on Sunday, so if you have any thoughts, sending them on Thursday or Friday will be much appreciated. Thanks in advance! 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
This is my review of the Boost DLL library: On 7/9/2015 2:13 PM, Vladimir Prus wrote:
Boosters,
I wanted to remind that the formal review of Boost.DLL library by Antony Polukhin is nearing the end - the last day to submit reviews is Sunday. Of course, not much discussion is likely to happen on Sunday, so if you have any thoughts, sending them on Thursday or Friday will be much appreciated. Thanks in advance!
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?
Yes. I vote for acceptance.
- How useful is it?
I view it as very useful as it provides a cross-platform implementation of loading a shared library and invoking functionality in that library. This is a common usage of programming in all major platforms.
- What's your evaluation of - Design
The design from the end-user's point of view is clear and consistent.
- Implementation
I did not look at the implementation.
- Documentations
The name of the library seems Windows specific, since DLL is the term that Windows uses for shared libraries. Would not Boost DLM ( for dynamic loadable modules ) or Boost Loadable Library be clearer ? I think the documentation is good and thorough but could use a general overview section which briefly explained what the library accomplishes and of what the general means of accomplishing it consists. The rest of the documentation is more than adequate. I could understand how to use the library fairly easily even without an overview but for the general end-user I think an overview is necessary.
- Tests - How much effort did you put into your evaluation?
I ran DLL's tests against a number of compilers on Windows, including gcc, clang, and VC++. I encountered some problems but not enough to make me think there was any serious problems in the design.
- Did you attempt to use the library? On what systems and compilers?
I ran the DLL tests on Windows with mingw/gcc-4.8.1, mingw-64/gcc-5.1, clang-3.6, clang-3.7 ( latest ), and VC++12. Whatever problems I found I believe the library developer will fix if/when they occur in regression testing.
On 12 July 2015 at 21:24, Edward Diener <eldiener@tropicsoft.com> wrote:
The name of the library seems Windows specific, since DLL is the term that Windows uses for shared libraries. Would not Boost DLM ( for dynamic loadable modules ) or Boost Loadable Library be clearer ?
If I remember correctly, there was a long discussion about the naming of the library before the majority seemed ok with DLL because it's explicitely only about loading libraries, not "modules"(which is misleading) nor "plugins" (which would require a lot more features). The name, if my memory is correct, was not particularly thought to be about the Windows context. Other libraries also already took the other names like Boost.SharedObject so it was not an option.
On Thu, Jul 9, 2015 at 2:13 PM, Vladimir Prus <vladimir.prus@gmail.com> wrote:
Boosters,
I wanted to remind that the formal review of Boost.DLL library by Antony Polukhin is nearing the end - the last day to submit reviews is Sunday. Of course, not much discussion is likely to happen on Sunday, so if you have any thoughts, sending them on Thursday or Friday will be much appreciated. Thanks in advance!
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?
I apologize for this late response, I got tied up the last few days and was unable to look at this more thoroughly. I did look at the code, and all of the documentation/examples. I just had a few discussion points: I'm sure some will find this library would be useful; I worked on a project that implemented the factory example in a Windows & Linux environment. Unfortunately, these types of systems are also brittle (ABI). Is there a way to add a symbol that acts similar to the soname automatically? If group A provides a boost::dll plugin with an explicit version, and then group B doesn't request that version when loading some symbol from the plugin, boost::dll automatically fails in all load functions. This way a provider of a plugin can force the user of a plugin to think about potential ABI problems through the boost::dll interface. The use-case might be too narrow though, especially since the importer of boost::dll should really think about these issues. However, is it worth discussing ABI issues a little more in the documentation, or at least point to a good external resource (the Drepper paper)? Someone who finds this library may be less knowledgeable of such issues. My other question was about the header-only design. Is there a reason why all of the code is being exported into the users codebase? Is it necessary? I think this should be a compiled + linked library, or it should be explained in the rationale. I'm guessing it can get interesting if this library itself were a pulled in as a DLL - is there a concern of plugins also use boost::dll but a different version? It wasn't obvious to me initially why this was header-only, this isn't template heavy library. Although, ASIO has a header-only mode option too. Also Niall's demangling thing sounds nice but complicated. I think runtime errors would be preferred over undefined behavior, so hopefully it can be done. Lee
On Mon, Jul 13, 2015 at 3:07 PM, Lee Clagett <forum@leeclagett.com> wrote:
My other question was about the header-only design. Is there a reason why all of the code is being exported into the users codebase? Is it necessary? I think this should be a compiled + linked library, or it should be explained in the rationale.
I've been thinking about this... The cost of having the library header-only in this case is symbol pollution, bringing lots of otherwise encapsulated information. Maybe non-header-only solution would be "cleaner" from a user's point of view? Rodrigo Madera
On 7/14/15 6:57 AM, Rodrigo Madera wrote:
On Mon, Jul 13, 2015 at 3:07 PM, Lee Clagett <forum@leeclagett.com <mailto:forum@leeclagett.com>> wrote:
My other question was about the header-only design. Is there a reason why all of the code is being exported into the users codebase? Is it necessary? I think this should be a compiled + linked library, or it should be explained in the rationale.
I've been thinking about this... The cost of having the library header-only in this case is symbol pollution, bringing lots of otherwise encapsulated information.
Maybe non-header-only solution would be "cleaner" from a user's point of view?
This is a recurring issue with boost libraries. Header only makes for a convenient library for many users - just include the header and try it out. On the other hand, for a large project where one is willing to invest more effort, a compiled library is attractive. I believe that for many libraries, it's possible to make the library such that one could have both by providing different #include for each type. This comment applies not to just this library but to others as well. Of course it wouldn't apply to all libraries. I would love to seem someone invest some effort to see if this is possible for this or some other library. Then if such an experiment were successful, we'd write up an article about it and include it in the boost body of work. Robert Ramey
2015-07-14 18:32 GMT+03:00 Robert Ramey <ramey@rrsd.com>:
On 7/14/15 6:57 AM, Rodrigo Madera wrote:
On Mon, Jul 13, 2015 at 3:07 PM, Lee Clagett <forum@leeclagett.com <mailto:forum@leeclagett.com>> wrote:
My other question was about the header-only design. Is there a reason why all of the code is being exported into the users codebase? Is it necessary? I think this should be a compiled + linked library, or it should be explained in the rationale.
I've been thinking about this... The cost of having the library header-only in this case is symbol pollution, bringing lots of otherwise encapsulated information.
Maybe non-header-only solution would be "cleaner" from a user's point of view?
This is a recurring issue with boost libraries. Header only makes for a convenient library for many users - just include the header and try it out. On the other hand, for a large project where one is willing to invest more effort, a compiled library is attractive. I believe that for many libraries, it's possible to make the library such that one could have both by providing different #include for each type. This comment applies not to just this library but to others as well. Of course it wouldn't apply to all libraries. I would love to seem someone invest some effort to see if this is possible for this or some other library. Then if such an experiment were successful, we'd write up an article about it and include it in the boost body of work.
This could be useful. I'll think of adding a BOOST_DLL_USE_LIBRARY macro and compiling DLL as a library -- Best regards, Antony Polukhin
On 15 July 2015 at 02:35, Antony Polukhin <antoshkka@gmail.com> wrote:
This could be useful. I'll think of adding a BOOST_DLL_USE_LIBRARY macro and compiling DLL as a library
Please don't go the macro route. A library that uses this built with the macro set one way linked against another library/application with the macro set another way is a disaster waiting to happen. If you really wish to do this, one way is to use macros to put the different implementations in different namespaces. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On 15/07/2015 19:35, Antony Polukhin wrote:
This is a recurring issue with boost libraries. Header only makes for a convenient library for many users - just include the header and try it out. On the other hand, for a large project where one is willing to invest more effort, a compiled library is attractive. I believe that for many libraries, it's possible to make the library such that one could have both by providing different #include for each type. This comment applies not to just this library but to others as well. Of course it wouldn't apply to all libraries. I would love to seem someone invest some effort to see if this is possible for this or some other library. Then if such an experiment were successful, we'd write up an article about it and include it in the boost body of work.
This could be useful. I'll think of adding a BOOST_DLL_USE_LIBRARY macro and compiling DLL as a library
Don't invent something new -- there's existing plumbing for this (see BOOST_ALL_DYN_LINK and friends). https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a16.BUILD:Conside...
2015-07-13 21:07 GMT+03:00 Lee Clagett <forum@leeclagett.com>:
I'm sure some will find this library would be useful; I worked on a project that implemented the factory example in a Windows & Linux environment. Unfortunately, these types of systems are also brittle (ABI). Is there a way to add a symbol that acts similar to the soname automatically? If group A provides a boost::dll plugin with an explicit version, and then group B doesn't request that version when loading some symbol from the plugin, boost::dll automatically fails in all load functions. This way a provider of a plugin can force the user of a plugin to think about potential ABI problems through the boost::dll interface.
I've been playing around with Boost.DLL in my toy project and solved that problem in a nasty way; libcore.so - contains all the functionality to load libraries and additionally contains a `BOOST_SYMBOL_EXPORT int my_library_version_1_2_7345` plugin1.so - plugin and `BOOST_SYMBOL_IMPORT int my_library_version_1_2_7345`. Links with libcore.so plugin2.so - plugin and `BOOST_SYMBOL_IMPORT int my_library_version_1_2_7345`. Links with libcore.so main - program itself. Linked with libcore.so, uses libcore.so functions to load plugins/libraries functions dynamically. Now, if libcore.so attempts to load library with different version (for example with `BOOST_SYMBOL_IMPORT int my_library_version_1_0_0001`), then loading a plugin fails. because of undefined symbol. Otherwise symbol is found in libcore.so and libraru loading succeeds.
The use-case might be too narrow though, especially since the importer of boost::dll should really think about these issues. However, is it worth discussing ABI issues a little more in the documentation, or at least point to a good external resource (the Drepper paper)? Someone who finds this library may be less knowledgeable of such issues.
This is hard to do it portably on library level. It's better to have that recipe described somewhere so that users could experiment with that. -- Best regards, Antony Polukhin
On 7/9/15 11:13 AM, Vladimir Prus wrote:
Boosters,
I wanted to remind that the formal review of Boost.DLL library by Antony Polukhin is nearing the end - the last day to submit reviews is Sunday. Of course, not much discussion is likely to happen on Sunday, so if you have any thoughts, sending them on Thursday or Friday will be much appreciated. Thanks in advance!
Could you update us on how many reviews have been submitted so far? Robert Ramey
participants (1)
-
Antony Polukhin -
Edward Diener -
Gavin Lambert -
Klaim - Joël Lamotte -
Lee Clagett -
Nevin Liber -
Robert Ramey -
Rodrigo Madera -
Vladimir Prus