Re: [boost] Re: shared_object added to files

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-12-17 15:35:54

At 06:14 PM 12/16/2001, mfdylan wrote:
 >--- 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.

A checksum-like requirement might be of use to catch errors.  If the header 
supplies a checksum (perhaps using metaprogramming tools), and the 
shared_library exposes what is supposed to be the same checksum, then a 
runtime check can be made.  I wouldn't be surprised if someone, somewhere 
has already solved this problem, by the way.

 >> 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)

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. 
Do objects in the shared_library use the same heap as the main program? 
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?

--Beman