Dynamic Library Load (Boost.DLL)

Library Submission

Note: you must be a logged in registered user in order to submit a library!
  • logo_linkweb_linkcomment 
    Add a row
Display Statistics
Reviews There are 0 reviews
There are 7 comments

Comment on This Page

  • grisumbras says:

    I've noticed, that while the library provides (kind of) non-throwing constructor versions and load overloads, it does not provide a non-throwing get. This overload could be useful for those who shun exceptions.

    • Anthony Polukhin says:

      `T& get<T>(string)` returns a reference, so making `T& get<T>(string, error&)` is not very nice. When we have an error to what object shall the reference refer to?

      There's a method `bool search_symbol(string&)` that does what you whant (http://apolukhin.github.io/Boost.DLL/boost/dll/shared_library.html#idp6904368-bb):
      Returns true if the loaded library contains a symbol with a given name. The `get` call will always succeed and throw nothing if call to `search_symbol(boost::string_ref )` member function with the same symbol name returned true.

  • ben.boeckel says:

    I read through the documentation and functionality-wise, things look great. I
    do have some higher-level questions to start with and I’ll get more specific
    towards the end (in general).

    I see that there is mixed usage of `boost::string_ref`, `boost::string_ref
    const&`, and `std::string const&` in the API functions. There is no documented
    rationale for the differences where they exist. I’d rather there be
    consistency, but rationale is good if that is not possible.

    When other sections are referenced, having them link directly would be nice to
    have so that I don’t need to go back to the table of contents to find out what
    is being referenced.

    There is a lot of repetition in the documentation. As an example, defining
    “symbol” early so that “symbol (variable or function)” does not need to be
    repeated over and over would be nice. A lot of repetition also occurs for
    overloads when other boost libraries document them together to make it easier
    to see all the ways functions named the same work.

    The documentation for function parameters often shows up after lots of
    exposition or out of order of the function’s arguments (or both). This made me
    do a double take multiple times to make sure I had read things properly. There
    are also very terse parameter names in the `shared_library` documentation such
    as `sl` versus `library` which is much clearer. For `error_code`, `ec` is
    acceptable since it is already a boost-ism.

    It would be nice if the examples used more C++11 idiomatic patterns. This is
    particularly visible in the examples with `for` loops which iterate using the
    index rather than iterators, range-based for loops, or `BOOST_FOREACH`. I also
    saw that `pl` was used as the namespace alias in the examples without it being
    an initialism of the full namespace or a rationale. It would also be nice to
    have an example with multiple plugins linked into an application statically
    since it seems that there would need to be a way to get all of the symbols
    required rather than a single one through `load_self`.

    For section names, are there section names which are reserved on different
    platforms (e.g., `.rodata` in ELF). Are section names statically checked that
    their length is no longer than 8 bytes?

    It seems that the CSS could use some help since notes, mentions of parameters
    and other API functions are not differentiated from other things which makes
    it harder to read.

    In the library_info documentation, one of the return values is documented as
    “unspecified” where it should probably be “platform dependent”. I also don’t
    think that private methods and members of the class need to be documented in
    the HTML documentation.

    In shared_library’s documentation, the parameter names are very terse when
    full words would work much better. The reasons for the various exceptions
    would also be nice to have instead of just having a list of exceptions which
    might be thrown. For the functions which take the name of a library, how are
    additional paths to search for non-full paths added to the search path. If no
    API is possible, adding documentation for the environment variables would be
    nice. Which makes me think that an API to get all shared libraries in a set of
    directories would be nice to have (but might be out-of-scope). For library
    names, can `”foo”` be used or does it always need to be `”foo” +
    shared_library::suffix()`? If the latter, why not allow the former since the
    latter is what basically every caller is going to end up doing anyways. Also,
    Apple loves throwing a curveball here since plugin library extensions should
    end in “.so” even though linked libraries end in “.dylib”. See Python module
    libraries for an example.

    All of the operator pages would probably make sense on a single page rather
    than on separate ones. The `operator <` documentation should also mention that
    the sorting is platform-dependent and not guaranteed to be stable between
    runs.

    In load_mode, there seems to be doubled up equal signs which might be a
    Doxygen bug, but still something to be aware of. It should also be mentioned
    that some of the values are only available on specific platforms (i.e.,
    `RTLD_*` on POSIX).

    The direct import_* functions don't mention how the shared library is
    reference counted if multiple symbols are loaded using these functions. Do
    they share a reference count with any already-opened shared_library instances
    for the given path?

    The documentation has lots of passive voice, "we" usage, spelling errors, and
    sub-optimal wording. I can send a file with the ones I found (except the
    passive voice) since they'd be noise on here. I can also file a pull request
    if you'd like.

    Overall, the library looks good but there is some polish that needs to be done
    to be a top-notch library. I'm looking forward to it 🙂 .

    • Renato Forti says:

      Hi,
      Thanks for the comment and a big work of code reviewing.
      Some of the issues with docs were fixed. Working on remaining issues.
      Any pull requests are welcomed.

    • polukhin says:

      Almost all the docs related issues were fixed. Some C++11 examples would be added later. Default Boost’s CSS were used, so this must be fixed on official Boost website. Maximum functionality was squeezed from Doxygen, not sure how to squeeze more.

      Good point with library extension. I’ll think of some nice way to deal with extensions, possibly new load_modes “append_native_extension”, “append_so_extension”, “append_dll_extension” would be useful.

      Library search paths were out of scope for some time. I’m still not sure that such functionality must be provided, because explicit specialization of paths seems right. However tests are full of ugly calls to `boost::filesystem::path shared_lib_path(…)` to get the absolute path to the plugin. This also does not seem right… Some experiments required to get the ideal solution, this’ll take some time.

  • Robert Ramey says:

    I’ve made a very cursory examination of the documentation. It seems understandable to me. Looks like serious effort. Definitely meets the requirement for the incubator.

    I do have one thing that I think should be addressed. As is well known I’m on a campaign to promote the usage of Type Requirements (C++ Concepts) in documentation and with compile time violation trapping in code. This library has a number of parameterized types such as:

    // documentation
    template
    boost::function< T >
    import_function(const boost::shared_ptr< shared_library > &, boost::string_ref);

    // implementation
    template
    boost::function import_function(const boost::shared_ptr& lib, boost::string_ref func_name) {
    return boost::dll::detail::refc_function(lib, &lib->get(func_name));
    }

    I presume that since it’s in the documentation this class is more than in implementation and thus meant to be used and understood by the library user. But here’s the problem. The user looks at the documentation above and has no indication as to what types can be used for the parameter T. Is any type permitted? e.g. void?. I look into the actual header (which I shouldn’t have to do) and see that there is a get in there. That could mean anything.

    Soooooo what is missing here is Type Constraints – at least in the documentation and preferable compile time checking in the code itself. Look at the other pages of this website – advice … and see what I recommend. Trust me on this. Doing this will add value to your library and increase that chances that boost will accept it. And if you find anything in there that I haven’t explained well, give me some feedback. This is very important to me and I am interested in improving this.

    Thanks for including your library in the Boost Library Incubator.

    Robert Ramey

    • Anthony Polukhin says:

      I’ve tried to tune the `import_function` method using static_assert and type_traits to recive better error mesages at compilation… and failed. Compilers first of all try to instantiate boost::function and complain about invalid use of incomplete type. Only after that a static_assert message is shown. Exactly the same things occur if I try to use Concepts from Boost.

      Much more correct solution would be to use Concepts in Boost.Function.

      Methods of DLL library except `import_function` and `import_function_alias` accept any template parameter `T` so there is no other suitable place for Concepts 🙁