-----Original Message-----
From: Laurent Guerby <[log in to unmask]>



>[Note: I'm not speaking for ACT here, it's just my humble programmer
>opinion on the multi-language issue.]
>
>> I beg to disagree: the codeview format as used by MSVC++ is pretty much a
de
>> facto standard for NT.
>
>   There's the Borland world, plus the Watson compiler seem to be used
>   a lot too. I talked about "standard", you talked about "de facto
>   standard" so we don't really disagree here ;-).

Except that if I recall correctly, Borland also uses the codeview approach,
and does support the standard stdcall and cdecl conventions, so differences
are mainly in the area of name mangling.  I don't know about the Watcom
compiler, but I'd be surprised if they didn't also use it.  This is of
course ignoring runtime system issues, but DLL's provide a fairly
straightforward mechanism for dealing with this.  (We're only disagreeing, I
think, on how we're drawing our distinctions).

>> The "won't work" tends to be mainly in the area of inheritance across the
>> language boundary.  Most other issues are pretty workable.

I agree with your general points about C vs C++

>
>   Also exceptions (language and system), tasking synchronization and
>   communication, interrupts.

I'll hazard some minor disagreement on this.  As far as tasking/threading
goes, pretty much all compilers I've run into for Windows use the underlying
threads api's, and can use the windows api's for synchronization and
communication.  Within an Ada DLL, it's also possible to have foreign
threads synchronize in our implementation because we wrap them with an Ada
context when they enter the DLL.  In the other direction, since the Ada
piece is an "add-on" to the basic thread representation, there is no problem
synchronizing within  a C/C++ dll.

I agree that exceptions are problematic.  Interrupts are a bit of a
non-issue, since you have to go into the DDK to use them, and you wind up
synchronizing at a higher level that's available to any high level language
that can utilize the windows Apis.

>   But there's a tradeoff not to be missed here: if you choose to mix
>   C++ and Ada 95, you may end up with a list of constructs to avoid
>   on both sides (that you may have learned the hard way, after the
>   design phase), so the gain may be less than expected against the
>   separate-executable method.

I also agree with this in general.  For the specific situation he mentioned,
though, it sounded like he was mainly concerned with GUI stuff in C++
interfacing with Ada for computation.   So, I think the specific situation
is likely to be somewhat more straightforward.

- Ed
>