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