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,8c8bbb1419c8e81a X-Google-Attributes: gid103376,public From: Ken Garlington Subject: Re: Waiver question Date: 1997/04/22 Message-ID: <335D0E73.4E92@lmtas.lmco.com>#1/1 X-Deja-AN: 236721050 References: <33585385.C8D@lmtas.lmco.com> Organization: Lockheed Martin Tactical Aircraft Systems Newsgroups: comp.lang.ada Date: 1997-04-22T00:00:00+00:00 List-Id: Robert I. Eachus wrote: > > In article <33585385.C8D@lmtas.lmco.com> Ken Garlington writes: > > > * Most existing DSP code is in C/C++. Therefore, reuse is easier > > if the new code is also written in C++. > > > Anyone have a reason to think this waiver shouldn't be approved? > > Sure, the first quoted statement indicates the author has no clue. > > Reuse of C is much easier from Ada than from C. > > Reuse of C is much, much easier from Ada than from C++. > > Reuse of C++ is all but impossible if the code requires any other > compiler, whether for C, Ada, C++, or COBOL. Note that this is a > compiler issue--using g++ and gcc or even g++ and gnat is > significantly easier than using a different underlying technology. > > Therefore if there is a significant amount of C++ to be reused, you > need to use one specific compiler, otherwise you are better off with > Ada 95. I believe the vendor is proposing using the same compiler used to develop the existing C++ code, although that's not explicit in the waiver. As for Ada 95, there is no such compiler for the TI DSP target in question, only an Ada 83 compiler. > > This was to some extent true with Ada 83, but with Ada 95 the > advantage of using Ada for interfacing to foreign code has > substantially improved, and not just because there exists a tool for > creating Ada package specifications from .h files. > > The real advantage from using Ada comes at link time. If you have > two C based products you have to interface to, and they have > conflicting names in them, you are going to be climbing the wall in C > or C++. In Ada 95 you can decide to link your program as separate > partitions, play compiler specific games in the library structure, or > actually go into one of the C programs and make changes. That second > choice sounds confusing so watch a real example: I have two COTS C > libraries I want to use in a Windows NT environment. I can build two > DLLs, one for the Ada binding to each COTS product, then write the > rest in Ada. At this point I don't need to care if there are > conflicts in the C names used. (Or it may be the case that one or > both of the DLLs are provided, and all I have to do is construct the > corresponding package spec.) Since the existing C/C++ code was developed by the same vendor, this should not be an issue. > > In theory, I can do the same thing in C, or for that matter in > Visual C++, if I am very careful never to require include files from > the two COTS packages in the same C source file. But there are other > gotchas, and I have been got several times. For example, if the C > code for one product replaces a standard c library operation, such as > malloc, getting things to link properly can be a horror. > > -- > > Robert I. Eachus > > with Standard_Disclaimer; > use Standard_Disclaimer; > function Message (Text: in Clever_Ideas) return Better_Ideas is... -- LMTAS - The Fighter Enterprise - "Our Brand Means Quality" For job listings, other info: http://www.lmtas.com or http://www.lmco.com