Fix compiler warnings when initializing extern variables

[martin-olivier]

Description

fix: gcc warnings when initializing extern variables

Changes include

• Bugfix (non-breaking change that solves an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (change that is not backwards-compatible and/or changes current functionality)

Checklist

• I have assigned this PR to myself
• I have added at least 1 reviewer
• I have tested this code
• I have added sufficient documentation in the code

[eyalroz]

Do you actually need the extern declaration, though?

[martin-olivier]

DYLIB_API marks the function / variable as extern "C" and also as __declspec(dllexport) on windows.

i don't know if compilers can do name mangling on variables but DYLIB_API will still be necessary for variables to apply __declspec(dllexport) on windows

[eyalroz]

If you need it to be extern "C", mark it that.

__declspec(dllexport) is what you use in the DLL; in the code using the DLL function I think you want __declspec(dllimport) .

At any rate, it's not DYLIB_API that you want to use. Or rather - you could define two macros, DYLIB_IMPORT and DYLIB_EXPORT.

Finally - what if the function is not extern-C? What if it's an overloaded C++ function?

[martin-olivier]

From what i have read __declspec(dllimport) seems useless when dll is loaded at runtime with LoadLibrary and GetProcAddress.

What if the function is not extern-C?

If the function is not extern "C", the compiler will do name mangling, making hard and non cross-(compiler / platform) way for the core to retreive symbols from the dynamic lib

What if it's an overloaded C++ function?

If multiple overloaded functions are marked as extern "C", the build of the dynamic library will fail because of multiple definition, since they will all have the same symbol name.

The only way i know to be able to have overloads on a dll is by passing throught an api :

// api.hpp

#include <string>

class api {
public:
    virtual ~api() = default;
    virtual void print(const std::string &req) = 0;
    virtual void print(const char *req) = 0;
}

// lib.cpp

#include "api.hpp"
#include "dylib.hpp"

class implem : public api {
public:
    void print(const std::string &req) override {
        std::cout << "std::string overload > " << req << std::endl;
    }
    void print(const char *req) override {
        std::cout << "char * overload > " << req << std::endl;
    }
}

DYLIB_API api *get_module() {
    return new implem;
}

// main.cpp

#include <memory>
#include "api.hpp"
#include "dylib.hpp"

int main() {
    dylib lib("./lib", dylib::extension);
    auto factory = lib.get_function<api *()>("get_module");
    std::unique_ptr<api> obj(factory());
    obj->print("first");
    obj->print(std::string("second"));
}

[eyalroz]

What if the function is not extern-C?

If the function is not extern "C", the compiler will do name mangling, making hard and non cross-(compiler / platform) way for the core to retreive symbols from the dynamic lib

But the whole library is brittle and platform-specific. Are you the library only supports C functions? Then the README is misleading. A C++ library for working with shared objects should absolutely support C++ functions. I'll open a separate issue.