C++: implementation of a class methods in a separated shared library

℡╲_俬逩灬. 提交于 2019-12-10 13:01:29

问题


I figure out I can have the implementation of parts of a class in a shared lib, as far as the symbols are loaded when used.

myclass.h
---

class C {
void method();
}

main.cpp
---

#include "myclass.h"
int main() {
    //dynamically load mylib.so using dlopen/dlsym/dlclose
        ...
    C *c = new C();
    c->method();
    delete c;
}

mylib.so compiled separately:
====
mylib.cpp
---

#include "mylib.h"
void C::method() {
...
}

This works fine.

However once I finished using C::method(), I would like to unload it, so I can change, recompile and reload it without having to restart the main program

int main() {
    //dynamically load mylib.so using dlopen/dlsym/dlclose
        ...
    C *c = new C();
    c->method();
    delete c;
    // close the lib, remove the handle...
         ....
    char pause;
    cin << pause; // before carrying on change the C::method, recompile it

    //dynamically load *Again* mylib.so using dlopen/dlsym/dlclose
        ...
    C *c = new C();
    c->method();
    delete c; 
}

The problem is that it does not unload the library when doing the first dlclose, probably because an instance of my class C exists. Any way to force this?

(using g++ 4.2.3, on Linux Ubuntu 10.04)


回答1:


Short Answer

It won't work the way you are doing it. There might also be other problems with your approach that haven't bitten you yet.

Why it doesn't work

Undefined symbols in your program/library are resolved at different times. On most systems, data references (global variables, class vtables, etc.) are always resolved when your program/library is loaded. Code references are resolved when they are first used on some systems ("lazy lookup"; it happens on Linux and Mac OS X, at least), unless some special options are set (RTLD_NOW parameter for dlopen or LD_BIND_NOW environment variable). Once these are resolved, no new lookup will take place.

If you dlopen your library with the RTLD_GLOBAL flag before the lazy lookup for a method is done, the method from your library will be used. The code reference to the method is now resolved; it won't change again. Your main program now officially uses symbols from your dlopened library, so dlclose will no longer close the library - dlclose only drops your explicit handle to it.

In short, you should only ever expect to unload libraries that you only use via explicit calls to dlsym.

What to do instead

What you can do instead is have your library provide a derived class implementation. You'd define your class C as an abstract base class:

class C
{
public:
    virtual void method();
};

In your separately-compiled library, you'd define a derived class and a function that creates an object of that derived class:

class D : public C
{
public:
    virtual void method();
};

void D::method()
{
    // ...
}

extern "C" C* createC()
{
    return new D();
}

Now, in your main program, you'd load the library using dlopen, get a function pointer to createD using dlsym and call it to get an object. When all objects are gone, you can call dlclose, recompile your library, and do the whole thing again:

typedef C* (*creatorFunction)();

int main()
{
    for(;;)
    {
        void *handle = dlopen("mylib.so", 0);
        creatorFunction create = (creatorFunction) dlsym(handle, "createC");

        C *c = (*create)();
        c->method();
        delete c;

        dlclose(handle);

        char pause;
        cin << pause;
    }
    return 0;
}



回答2:


Thanks for help guys, just a notice :

Don't forget in C class to initialise method to zero (this class is out of the shared library) , and to set a virtual destroyer to default

If you want to know what flag is 0 for dlopen --> it's RTLD_LOCAL



来源:https://stackoverflow.com/questions/8806630/c-implementation-of-a-class-methods-in-a-separated-shared-library

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!