Re: shared_object added to files

From: mfdylan (dylan_at_[hidden])
Date: 2001-12-17 18:19:40

--- In boost_at_y..., "Jeff Garland" <jeff_at_c...> wrote:
> 
> 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).
> 
As I explained it's not designed for implicitly loaded shared 
libraries, but rather for libraries explicitly loaded at runtime.
In this case you generally don't want to use C++ functions, but 
rather "C" linkage functions that return pointers to C++ abstract 
base classes (so that all calls are made through the vtable).

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

But when you load your library at runtime you at least have control 
over what order the libraries initialise themselves in.  It's then up 
to you to keep all dependent file-scope objects in the same file.
> 
> > Do objects in the shared_library use the same heap as the main 
program?
> 
> Yes.

Not necessarily.  Under Win32 it is quite possible for a DLL to be 
statically linked to a copy of the C runtime library, and thus any 
and only memory allocated by it must be freed by it.  So if you 
provide a function that returns allocated memory (with new or 
malloc), you must also provide one to free it.
But generally you can avoid this by dynamically linking to the C 
runtime library and having your application do the same.
I've never had this problem under Unix, but then I've never 
explicitly told the compiler to statically link with the C runtime 
library.
> 
> No, ACE uses the strategy described above.  On UNIX all the 
DECLSPEC macros are
> undefined and on windows as described above...
> 
Unix has no way that I'm aware of for specifying that an entry point 
with external linkage should NOT be exported from a shared object.  
To me this is a mistake, as for instance in a recent project where we 
compiled some old code into a shared object that was used purely for 
reading files from an older software version.  The shared object made 
use of older versions of some our library classes, that were not 
compatible with the newer versions.  Under Windows this was no 
problem, but under some flavours of Unix for instance, the destructor 
for the wrong version of the class was getting called and causing 
mayhem.  We had to rename the class to avoid the problem.
I'd still like to find a solution to this, if anyone has one, by the 
way...

Dylan