On Fri, Jul 3, 2015 at 10:50 AM, Vladimir Prus 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

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