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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,976a050e0f89277c X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP Date: 1998/04/26 Message-ID: X-Deja-AN: 347805963 References: <352A79C2.15FB7483@nathan.gmd.de> <1998Apr10.073110.1@eisner> X-Complaints-To: usenet@news.nyu.edu X-Trace: news.nyu.edu 893595694 10863 (None) 128.122.140.58 Organization: New York University Newsgroups: comp.lang.ada Date: 1998-04-26T00:00:00+00:00 List-Id: Joe said <> At the level we are talking about here, which is programmers who have a reasonable working understanding of the issues in interfacing to other languages, there are lots of Ada programmers who qualify. Indeed this is the kind of knowledge that every Ada programmer should have, and the great majority of Ada programmers are, in my experience, quite knowledgable in this area. I judge this from the kind of questions we get in our support activities. Sure there are some tricky points and good programmers are always working to improve their knowledge in all areas of the language. I suspect the fact that you can make this statement means you are trying to use Ada with insufficient expertise. Your continued problems in the interfacing area are additional evidence that this may be the case. Perhaps you should arrange for some appropriate training activities for your Ada programmers. We are not talking about needing a PhD in programming languages here, just the level of knowledge that any Ada programmer working on a serious Ada project should have. <> Of course not, since neither C nor Fortran 77 have any provisions for interfacing to other languages, so it is indeed the case that there are problems in interfacing in a portable manner from C to Fortran 77. Note that problems in interfacing using other languages than Ada, languages that pay no attention to the difficult problems of interfacing, are unlikely to be indicative of the performance of Ada 95 in this area, a language which uniquely among commonly used languages *does* worry about the issue of interfacing to other languages. An interesting indication of this is that the validation suite for Ada contains C, Fortran, and COBOL code, to be used in tests of the interfacing capability. The interfacing tests involved here are 100% portable, and expected to run without modification to either the Ada or the C/Fortran/COBOL code in any tested environment supporting the relevant languages. <> This probably indicates a lack of knowledge about how Ada handles this problem (Joe indicates later that he is not familiar with the technical details). The approach in Ada is that the entire responsibility of correct interface is placed on the Ada compiler system. For example, when we write: type x is record a : Interfaces.C.int; b : Interfaces.C.char; end record; pragma Convention (C, x); the Ada compiler is responsible for laying out the type x identically to the corresponding C record in the particular environment in which the Ada compiler operates. Yes, this is a huge pain, but it is a pain for the Ada compiler implementor, who has to find out how to do this, *not* for the Ada programmer. <> The level at which I would like a report is indeed more detailed than your "we have problems" general claim. We want to see a specific instance of the kind of interfacing problems you are having to see which category it is in: 1. Lack of knowledge of Ada programmers involved 2. Incorrect Ada 95 implementation 3. Genuine problem in Ada 95 language definition You tend to assume 3, partly because of the strange logic that says "since I have had problems in the past with other languages, I am sure I will have problems with Ada 95 in the future." This is, as noted above, indeed strange logic, since one of the important design features in Ada 95 is precisely to recognize the kind of problems you have had in the past, and fix them. On one occasion in comp.lang.cobol, someone asked how to interface COBOL to C. This cannot be done portably in a direct manner, since neither C nor COBOL has anything to say about portable language interfacing, but I pointed out that an interesting and completely portable approach was to use an Ada 95 layer as glue, since Ada 95 can portably interface to both languages. I suspect 1 or perhaps 2 may be more likely to be the source of problems. <> That's perfectly reasonable. Indeed "coders" often don't have the perspective to make a choice. What is important is that whoever makes the decision, no matter what their title be, have the kind of technical knowledge that is needed to make a sound decision. All too often managers don't know enough of the details to make sensible decisions. I have seen managers choose a programming language when they knew absolutely nothing about the language at all. By the way "coders" is a rather contemptous term for a manager to use. I trust you are not operating in an environment where you really have people coding who understand nothing in the programming process other than actual coding. That was a model used by many COBOL shops in the 60's and 70's (the very ones who give us the Y2K headaches today), and is largely discredited. Certainly in the kind of technical area for which Ada is used, I would look for programmers with excellent knowledge of both Ada and the entire programming process to be involved. <> I am always suspicious of people lumping C/C++ together in one breath as though they are one language. They are most definitely NOT one language. If you look at these posts, you will find the following clear pattern. In the case of C, the Ada 95 definition is adequate. The one remaining glitch of which I am aware, namely the issue of passing structs' by value (not such a common occurrence) is handled by the pragma C_Pass_By_Copy, implemented compatibly in GNAT and Intermetrics (i.e. including Green Hills). In the case of C++, no C++ standard was in effect at the time that Ada was standardized (indeed as I assume you know, the C++ standard is very recent). So there is no standardized method in the Ada 95 RM for interfacing directly to C++. In practice there is no problem because C and C++ can interoperate, and Ada and C can interoperate, so a portable solution can be created by using a C interface layer (this is the sort of knowledge that should be at hand in any work you do in this area). GNAT does provide a set of pragmas for direct interfacing to C++, but these are not a standard part of the language. The ARA technical committee has made some progress towards a common set of interfaces for C++, but this work is not yet complete. Quite a few of the posts you are talking about have to do with using these special GNAT features. This is an area that you cannot expect Ada programmers to be familiar with, and indeed we definitely spend time helping our supported customers use these GNAT-specific problems. But for most purposes the use of an intermediate C layer solves the problems. Whether this is true in your case (or whether your case involves C++ at all) remains to be seen pending some more technical details on the problems that you actually face. <> We look forward to it. A list would be very instructive, but even ONE clear technical answer would help get this conversation out of the rather uninformative philosophical level onto a technical level. Robert Dewar