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