Re: [Boost-users] Boost.DLL formal review is ongoing

Subject: Re: [Boost-users] Boost.DLL formal review is ongoing
From: Rodrigo Madera (rodrigo.madera_at_[hidden])
Date: 2015-07-10 15:26:39

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