Re: shared_object added to files

From: mfdylan (dylan_at_[hidden])
Date: 2001-12-16 18:14:08

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 07:28 PM 12/13/2001, mfdylan wrote:
> 
>  >For anyone interested I added shared_object.zip to files which is
>  >basically a very thin class wrapper for shared object usage, with
>  >support for Win32 (LoadLibrary etc) and POSIX (dlopen etc).
>  >Obviously I can't do anything to make it truly typesafe as such, 
but
>  >at least it prevents the need for ugly casts in your code.
>  >dlopen/GetProcAddress assumes sizeof(void*) == sizeof
(object_type*)
>  >so obviously you may not be able to use it with certain pointers 
to
>  >members (not recommended anyway!).
> 
> I'm certainly interested, but know nothing about shared libraries.
> 
> Could you explain what they are good for and what they aren't good 
for?

Well this is the subject of much phisophical disagreement but 
essentially they are good for:

a) Space and time saving where the same library is used heavily by 
lots of applications.  For instance the standard C/C++ library is 
usually a shared library, which means the code is stored on disk once 
and loaded into memory just once and all applications use the same 
code.  In this case however the application loads the library 
implicitly at load-time, and there is no need to use any explicit 
calls to access it (ie shared_object would not be needed).

b) Run-time plugin technology.  If you define a particular interface 
that a shared library must expose through exported functions, then an 
application can load that library at run-time and make use of the 
functionality it offers, without having known anything about it at 
compile time.  It is for this case that something like shared_object 
is useful.

They have other practical benefits such as reducing link times and 
enabling easier patches/replacements, but this is somewhat offset by 
the requirement to make sure the user not only has the library, but 
has the right version of the library in the right place (or has 
configured the environment properly so the application can find it).

> 
> Are they really as type unsafe as you indicate above?  Don't 
programmers 
> get confused and make mistakes regularly?
> 
Unfortunately yes.  The problem is best alleviated by making the 
actual shared library interface as simple as possible.  My preference 
is for one function that takes no arguments and returns a pointer to 
an abstract base class.
Under Win32 there exists a primitive name mangling scheme (basically 
you just add an @ and then a number representing the number of bytes 
the arguments take up) that attempts to alleviate the problem a 
little, but I doubt it helps much.

> Why do you call the class shared_object?  Can the shared object 
really be a 
> C++ object, or is it limited to a free function?
> 
"shared object" is what shared libraries/dynamic link libraries are 
called under unix. Perhaps shared_library would be better.
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.

> Is it really as simple as your code would seem to indicate?
> 
Pretty much :o)

Dylan