RE: [boost] Re: shared_object added to files

From: Jeff Garland (jeff_at_[hidden])
Date: 2001-12-17 17:44:27

>  >A C++ object can feasibly be exported directly from a shared library
>  >(if it's at file or namespace-scope and has external linkage), but I
>  >wouldn't recommend it.  You can also export an entire C++ class
>  >interface, so that non-virtual functions can be called, but if you
>  >really are loading the library at runtime you need to know the name-
>  >mangling scheme which is obviously not ideal!
>  >That's why by far the best way of using run-time shared libraries is
>  >to define an ABC and export a 'factory' function that creates objects
>  >of a derived class and returns back an ABC pointer.  All calls to the
>  >object are then virtual and nothing else from the class needs to be
>  >exported.

In my experience with unix shared libraries an entire class is automatically
available by linking it into a shared object using the linker.  Windows is more
difficult, requiring the programmer to manage the dll namespace.  A typical
strategy for managing this on windows is as follows:
  //in some_class.h
  class SOMELIB_DECLSPEC_ some_class
  {

  };

When the library is compiled SOMELIB_DECLSPEC_ is defined to
__declspec(dllexport).  When a client compiles it is defined to
__declspec(dllimport).  This allows the entire class to be available in the
windows.dll.  If you look at regex.hpp you will see a similar strategy employed.

Since no code knows the name mangling strategy and everything is accessible I
don't understand what shared_object will provide? (note, I haven't looked at the
code).

>  >
>  >> Is it really as simple as your code would seem to indicate?
>  >>
>  >Pretty much :o)
>
> It seems a real complication would be specifying what can or can't be
> placed in the shared_library, and any restrictions on how such objects are
> used.  Issues like order of initialization would also have to be specified.

Order of initialization of file scope statics in shared libraries is impossible
to control.  The usual wrapper function or init object approaches must be
applied.

> Do objects in the shared_library use the same heap as the main program?

Yes.

> Etc.
>
> Every aspect of behavior in anyway different from normal C++ would have to
> be described.
>
> Or does such a description already exist somewhere?
>
> Does ACE, for example, supply such a component?  POSIX?

No, ACE uses the strategy described above.  On UNIX all the DECLSPEC macros are
undefined and on windows as described above...

Jeff