On 8/31/07, Ken Raeburn <raeburn@xxxxxxxxxxx> wrote:
> Is it possible, or safe, generally, to get two C++ runtimes loaded
> into one address space via different shared libraries, as long as you
> don't pass C++ objects or exceptions around between them?
Your success in mixing two runtimes depends on the details of the
ABIs involved. Any number of problems can cause interference,
and once you have interference, the application is at risk of failure.
> I'm evaluating using C++ internally for a library, to get limited use
> of a few features like exception handling and templates, maybe an STL
> container template or two. The API for the library in question is
> purely a C API, and would stay that way. So aside from this shared
> library dragging in the C++ runtime code, it should theoretically be
> transparent to the application that C++ is being used. All API
> functions would trap exceptions and turn them into error codes, all
> storage allocations have deallocation functions provided too so new/
> malloc should be an internal distinction only, etc.
The most likely problem will be mangled names. Do the two ABIs
use the same mangling scheme? If so, you could have a problem
with a function from one ABI stepping on another. You can reduce
this problem by forcing bindings to a particular library, which is
pretty much automatic on Windows, but requires extra work on
Unix systems. You can also, on some systems, restrict the set of
symbols. Visible to other libraries.
Of your list of features, the exceptions are the biggest problem. They
require that both exception handling libraries be able to coexist with
the other. They also require that the typeid/typeinfo structures be able
to coexist with each other.
It is possible to write C++ so that it has no dependence on the C++
run-time library, which makes meeting your goal much easier. The
details of the language restrictions vary between compilers, but...
Don't use the global operators new and delete.
Don't use exceptions. Set the compiler option that turns them off.
Don't use RTTI functions.
If you use the standard library, make sure you link it statically into
your library and restrict the resulting symbol scope. (E.g. using
map files.)
In summary, it can be done but you'll need to manage more symbols
than you'd expect.
--
Lawrence Crowl
