Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

classes and static variables in shared libraries

I am trying to write something in c++ with an architecture like:

App --> Core (.so) <-- Plugins (.so's)

for linux, mac and windows. The Core is implicitly linked to App and Plugins are explicitly linked with dlopen/LoadLibrary to App. The problem I have:

  • static variables in Core are duplicated at run-time -- Plugins and App have different copys of them.
  • at least on mac, when a Plugin returns a pointer to App, dynamic casting that pointer in App always result in NULL.

    Can anyone give me some explanations and instructions for different platforms please? I know this may seem lazy to ask them all here but I really cannot find a systematic answer to this question.

    What I did in the entry_point.cpp for a plugin:

    #include "raw_space.hpp"  #include <gamustard/gamustard.hpp>  using namespace Gamustard; using namespace std;  namespace {   struct GAMUSTARD_PUBLIC_API RawSpacePlugin : public Plugin   {     RawSpacePlugin(void):identifier_("com.gamustard.engine.space.RawSpacePlugin")     {     }      virtual string const& getIdentifier(void) const     {       return identifier_;     }      virtual SmartPtr<Object> createObject(std::string const& name) const     {       if(name == "RawSpace")       {         Object* obj = NEW_EX RawSpaceImp::RawSpace;         Space* space = dynamic_cast<Space*>(obj);         Log::instance().log(Log::LOG_DEBUG, "createObject: %x -> %x.", obj, space);         return SmartPtr<Object>(obj);       }       return SmartPtr<Object>();     }    private:     string identifier_;   };    SmartPtr<Plugin> __plugin__; }  extern "C" {   int GAMUSTARD_PUBLIC_API gamustardDLLStart(void) throw()   {     Log::instance().log(Log::LOG_DEBUG, "gamustardDLLStart");     __plugin__.reset(NEW_EX RawSpacePlugin);     PluginManager::instance().install(weaken(__plugin__));     return 0;   }    int GAMUSTARD_PUBLIC_API gamustardDLLStop(void) throw()   {     PluginManager::instance().uninstall(weaken(__plugin__));     __plugin__.reset();     Log::instance().log(Log::LOG_DEBUG, "gamustardDLLStop");     return 0;   } } 
  • like image 269
    abel Avatar asked Mar 24 '10 04:03

    abel


    People also ask

    Are static variables shared between classes?

    static attributes exist independently of any instances of a class and may be accessed even when no instances of the class have been created. You can compare a static variable with a shared variable. A static variable is shared by all the instances of a class. Note A class and an interface can declare static variables.

    What is the difference between static library and shared library?

    Static libraries take longer to execute, because loading into the memory happens every time while executing. While Shared libraries are faster because shared library code is already in the memory. In Static library no compatibility issue has been observed.

    What are the differences between static and dynamic shared libraries?

    Static: happens as the last step of the compilation process. After the program is placed in the memory. Dynamic: shared libraries are added during the linking process when executable files and libraries are added to the memory.

    Can program access the global variables value of DLL or dynamic library?

    In reality, "yes" the processes do have full "access" to the globals, at the very least through the funtion calls to the library.


    1 Answers

    Some Background

    Shared libraries in C++ are quite difficult because the standard says nothing about them. This means that every platform has a different way of doing them. If we restrict ourselves to Windows and some *nix variant (anything ELF), the differences are subtle. The first difference is Shared Object Visibility. It is highly recommended that you read that article so you get a good overview of what visibility attributes are and what they do for you, which will help save you from linker errors.

    Anyway, you'll end up with something that looks like this (for compiling with many systems):

    #if defined(_MSC_VER) #   define DLL_EXPORT __declspec(dllexport) #   define DLL_IMPORT __declspec(dllimport) #elif defined(__GNUC__) #   define DLL_EXPORT __attribute__((visibility("default"))) #   define DLL_IMPORT #   if __GNUC__ > 4 #       define DLL_LOCAL __attribute__((visibility("hidden"))) #   else #       define DLL_LOCAL #   endif #else #   error("Don't know how to export shared object libraries") #endif 

    Next, you'll want to make some shared header (standard.h?) and put a nice little #ifdef thing in it:

    #ifdef MY_LIBRARY_COMPILE #   define MY_LIBRARY_PUBLIC DLL_EXPORT #else #   define MY_LIBRARY_PUBLIC DLL_IMPORT #endif 

    This lets you mark classes, functions and whatever like this:

    class MY_LIBRARY_PUBLIC MyClass {     // ... }  MY_LIBRARY_PUBLIC int32_t MyFunction(); 

    This will tell the build system where to look for the functions when it calls them.

    Now: To the actual point!

    If you're sharing constants across libraries, then you actually should not care if they are duplicated, since your constants should be small and duplication allows for much optimization (which is good). However, since you appear to be working with non-constants, the situation is a little different. There are a billion patterns to make a cross-library singleton in C++, but I naturally like my way the best.

    In some header file, let's assume you want to share an integer, so you would do have in myfuncts.h:

    #ifndef MY_FUNCTS_H__ #define MY_FUNCTS_H__ // include the standard header, which has the MY_LIBRARY_PUBLIC definition #include "standard.h"  // Notice that it is a reference MY_LIBRARY_PUBLIC int& GetSingleInt();  #endif//MY_FUNCTS_H__ 

    Then, in the myfuncts.cpp file, you would have:

    #include "myfuncs.h"  int& GetSingleInt() {     // keep the actual value as static to this function     static int s_value(0);     // but return a reference so that everybody can use it     return s_value; } 

    Dealing with templates

    C++ has super-powerful templates, which is great. However, pushing templates across libraries can be really painful. When a compiler sees a template, it is the message to "fill in whatever you want to make this work," which is perfectly fine if you only have one final target. However, it can become an issue when you're working with multiple dynamic shared objects, since they could theoretically all be compiled with different versions of different compilers, all of which think that their different template fill-in-the-blanks methods is correct (and who are we to argue -- it's not defined in the standard). This means that templates can be a huge pain, but you do have some options.

    Don't allow different compilers.

    Pick one compiler (per operating system) and stick to it. Only support that compiler and require that all libraries be compiled with that same compiler. This is actually a really neat solution (that totally works).

    Don't use templates in exported functions/classes

    Only use template functions and classes when you're working internally. This does save a lot of hassle, but overall is quite restrictive. Personally, I like using templates.

    Force exporting of templates and hope for the best

    This works surprisingly well (especially when paired with not allowing different compilers).

    Add this to standard.h:

    #ifdef MY_LIBRARY_COMPILE #define MY_LIBRARY_EXTERN #else #define MY_LIBRARY_EXTERN extern #endif 

    And in some consuming class definition (before you declare the class itself):

    //    force exporting of templates MY_LIBRARY_EXTERN template class MY_LIBRARY_PUBLIC std::allocator<int>; MY_LIBRARY_EXTERN template class MY_LIBRARY_PUBLIC std::vector<int, std::allocator<int> >;  class MY_LIBRARY_PUBLIC MyObject { private:     std::vector<int> m_vector; }; 

    This is almost completely perfect...the compiler won't yell at you and life will be good, unless your compiler starts changing the way it fills in templates and you recompile one of the libraries and not the other (and even then, it might still work...sometimes).

    Keep in mind that if you're using things like partial template specialization (or type traits or any of the more advanced template metaprogramming stuff), all the producer and all its consumers are seeing the same template specializations. As in, if you have a specialized implementation of vector<T> for ints or whatever, if the producer sees the one for int but the consumer does not, the consumer will happily create the wrong type of vector<T>, which will cause all sorts of really screwed up bugs. So be very careful.

    like image 179
    Travis Gockel Avatar answered Oct 04 '22 13:10

    Travis Gockel