[tsimionescu]

You still do the same thing that you would when calling a C library: you serialize your STL objects into plain C objects, pass them to the external library, and deserialize back. If you need callbacks, you make sure that they catch any exception and return an error code. It's really no different from virtually any other C++ interop.

There are a few languages that interop with C++ at a deeper level, essentially building a small part of a C++ compiler into their runtime. But they're relatively obscure - Clasp, an implementation of Common Lisp, is probably the only one that can really take an arbitrary C++ object (say, an std::vector<std::list<int>>) as an input to a Common Lisp function and work with it.

[MaxBarraclough]

> There are a few languages that interop with C++ at a deeper level, essentially building a small part of a C++ compiler into their runtime

The other approach is to compile to C++ source.

[bluGill]

now interoperability costs performance for all the serialize/deserialize operations and so the language is too slow to be practical.

[MaxBarraclough]

The bookkeeping overheads might be trivial though. If it boils down to a handful of instructions per call, that's probably not so bad, depending on context. If large buffers are being copied, that's a problem, but hopefully that can generally be avoided.

[sitzkrieg]

not an ada issue