Release 2.0.0 (Breaking changes)

[martin-olivier]

Changelog

Dylib class is now RAII compliant

open(), close() and default constructor are not available anymore

Dylib constructor changes

// old API
dylib lib("./libs/libfoo", dylib::extension);

// new API
dylib lib("./libs", "foo");

The dylib class can now load a dynamic library from the system library path

// Load "foo" library from the system library path

dylib lib("foo");

The dylib class will now automatically add os decorations (os prefix and suffix) to the library name, but you can disable that by setting decorations parameter to false

// Windows -> "foo.dll"
// MacOS   -> "libfoo.dylib"
// Linux   -> "libfoo.so"

dylib lib("foo");

// Windows -> "foo.lib"
// MacOS   -> "foo.lib"
// Linux   -> "foo.lib"

dylib lib("foo.lib", false);

Changes on get_function return type

The return type of get_function is now a function pointer instead of an std::function

// old API
std::function<double(double, double)> adder = lib.get_function<double(double, double)>("adder");

// new API
double (*adder)(double, double) = lib.get_function<double(double, double)>("adder");

Changes on handle_error exception

handle_error exception is now called load_error

try {
    dylib lib("foo");
    lib.get_function<double(double, double)>("adder");
}

// old API
catch (const dylib::handle_error &e) {
    std::cout << e.what() << std::endl;
}

// new API
catch (const dylib::load_error &e) {
    std::cout << e.what() << std::endl;
}

DYLIB_API is not available anymore

To ensure the functions and variable of your future dynamic library will be exported on windows, you can use the following macro

#if defined(_WIN32) || defined(_WIN64)
#define LIB_EXPORT __declspec(dllexport)
#else
#define LIB_EXPORT
#endif

Or, you can add the following cmake rule that will export all symbols on windows

if(MSVC)
    set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS TRUE)
endif()

Make sure to mark the functions and variables you want to export as extern "C" to avoid name mangling

Cmake rule that disables lib prefixes is now useless

Since dylib now handles lib prefixes, you will need to remove the following cmake rule when building your dynamic libs

# remove the following rule from your cmakelists if you was using it with dylib 1.X.X
set_target_properties(target PROPERTIES PREFIX "")

Thanks

Huge thanks to @eyalroz for his help and contributions that made this update possible !

---

This discussion was created from the release 2.0.0.