From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2e11aa5522d5cc28 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Mixing Ada and C++. Is a good idea? Date: 1997/11/21 Message-ID: #1/1 X-Deja-AN: 291230518 References: <1997Nov21.064154.1@eisner> X-Complaints-To: usenet@news.nyu.edu X-Trace: news.nyu.edu 880119176 27034 (None) 128.122.140.58 Organization: New York University Newsgroups: comp.lang.ada Date: 1997-11-21T00:00:00+00:00 List-Id: Larry says <> First, one cannot speak for "Ada and all its fans" at any time. Given the many ludicrous postings to CLA, one could never expect the supposed fans of Ada to agree unanimously on anything sensible :-) However, it clearly is the case that Ada 95 very much takes the position that other languages have an important place. A great deal of effort went into refining the already superior features of Ada 83 in this area. At no time did any of those involved give any other signal than that this was an extremely important part of the language. So I think you can definitely say that Ada 95 and its knowledgable advocates absolutely agree that there are places for other languages, most notably in regard to reuse of existing libraries. As to Larry's "shame it is required", you cannot possibly expect "automatic" interface. In fact it is this completely ill-thought out wish that leads to some of the weaknesses in the Ada 83 model. These are weaknesses of under-specification *at the language level*. The thought in Ada 83 was that if you provide pragma Import (C, xxx), then procedure xxx will indeed automatically interface with C on that platform. But that is sloppy thinking. The trouble is that the parameter passing model is different at the semantic level between C and Ada. This means that a correspondence has to be established which involves choices that show up at a high level of abstraction in the user code, and cannot be buried in the code generation. As an example, if we have a C formal parameter that is of a struct type (NOT a pointer to struct), then how should it be modeled on the Ada side. There are two possibilities: As a record type As a pointer to record type Ada 83 had nothing to say in this area, Ada 95 chooses the pointer approach (though this particular case is a tricky one, and the ARA agreed on the additional pragma C_Pass_By_Copy to resolve the trickiness. The fact that the ARA considers the specification of the mapping in this case to be of sufficient importance to warrant inter-vendor agreement on an appropriate pragma to resolve a remaining insufficiently specified point should of itself be an indication of the importance attached to this issue). Actually this seems to be the only case not 100% handled in C, Fortran, and COBOL interface protocols in Ada 95 (and with the new pragma, which is implemented by all Ada 95 vendors, or should be!, that little hole is plugged). Now C++ and Java interface issues are not yet resolved (a reflection of the fact that C++ was not standardized, and Java did not exist, at the time of the Ada 95 design completion), but work proceeds on to work out the best possible common interface for Ada 95 (e.g. at Tri-Ada, Intermetrics and Ada Core Technologies agreed to work together on trying to achieve maximum practical commonality in interface to Java). There simply is no such focussed concern on this issue when it comes to other languages. If you want to level a charge against fans of a language of ignoring other languages, that charge lies much more accurately when applied to other languages than Ada 95! Robert Dewar Ada Core Technologies