> That's the "C-level" interface I mentionned, it is always possible > to do so on most system. Interfacing C and Ada 95 is easy and > standard with all Ada 95 compiler I know. Proof: the thin bindings > to C API are no longer vendor-specific as it was the case in Ada > 83. > > > Of course, it's always possible to make things work, Not always!! > it may even be > easy if your compiler vendor is dedicated to support it (and it's a > good thing ;-). > > No one has mentioned what we have found is the number one problem with mixing Ada and C++, and that is controlling the elaboration of class object instances. Ada has a well defined API (adainit) that can be called, but C++ doesn't (in the numerous compilers we have used). Sure all the syntax of interfacing is achievable (even the mangled names can be deleted if using "#extern C") but important C++ objects like c++ stream-io cannot be guaranteed to have been initialized by the time you call the C++ routine. The best bet is to use the same venders compiler for both languages, or by making C++ the main, and having it call the adainit (which some Ada 83 had severe limitations with, such as no tasking). We have experienced cases where we could NOT get the executable to work - it crashed in c++ stream-io. This was after breaking apart C++ library modules until we could find the smallest piece to include to get objects elaborated, but the c++ vendor didn't provide a small enough piece (since it also included "main" - a kinda important only-1 in a executable). -scott ps. anyone know if the ISO standard for C++ will include elaboration control at the API level?