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: eachus@spectre.mitre.org (Robert I. Eachus) Subject: Re: Waiver question Date: 1997/04/21 Message-ID: #1/1 X-Deja-AN: 236468026 References: <33585385.C8D@lmtas.lmco.com> Organization: The Mitre Corp., Bedford, MA. Newsgroups: comp.lang.ada Date: 1997-04-21T00:00:00+00:00 List-Id: 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. 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.) 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...