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: f849b,d275ffeffdf83655 X-Google-Attributes: gidf849b,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public X-Google-Thread: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: 1108a1,d275ffeffdf83655 X-Google-Attributes: gid1108a1,public X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public X-Google-Thread: 101b33,d275ffeffdf83655 X-Google-Attributes: gid101b33,public X-Google-Thread: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Ada vs C++ vs Java Date: 1999/01/19 Message-ID: #1/1 X-Deja-AN: 434357625 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: <36A37219.72198FBE@west.raytheon.com> Organization: Intermetrics, Inc. Followup-To: comp.lang.ada,comp.lang.c++,comp.vxworks,comp.lang.java,comp.java.advocacy,comp.realtime,comp.arch.embedded,comp.object,comp.lang.java.programmer Newsgroups: comp.lang.ada,comp.lang.c++,comp.vxworks,comp.lang.java,comp.java.advocacy,comp.realtime,comp.arch.embedded,comp.object,comp.lang.java.programmer Date: 1999-01-19T00:00:00+00:00 List-Id: Ken Keys (klkeys@west.raytheon.com) wrote: : Matthew Heaney wrote: : : > This is a weak argument. The Ada front end marketed by AverStar : > (formerly Intermetrics) emits human-readable C code, and therefore you : Well it is readable by a C compiler. "Human-readable" is another matter. This variant of our Ada 95 front end compiles into optimized ANSI C, that is actually designed to be human readable as well, to simplify manual debugging (it generates #line directives so that a "C" debugger will display and step through the Ada source rather than the C intermediate). For typical Ada code, you end up with pretty "typical" C code, though the identifiers (inherited from the Ada program) are probably longer than some C programmers are used to ;-). If requested, it will take advantage of the C++ "namespace" feature in the output, to provide a more natural mapping for Ada package scopes. It will also copy over comments into the generated C code if requested. : > can use it where-ever there's a C compiler available. If you want a : Not necessarily. There are, for instance, C compilers available for : certain 8 bit micros where not every program that can be compiled can be : run on the target. Writing a program that will actually run requires : some concessions on the part of the programmer. The Ada translator, not : being aware of these concessions might not emit C code which can be : compiled into a runable program. It doesn't emit very "exotic" C code. Certainly any "validated" ANSI C compiler could handle it ;-), and probably most usable C compilers, even for microcontrollers. : ... Moreover, it could not be considered a : validated Ada implementation if the target didn't have enough resources : to support the full spectrum of Ada language features. That doesn't mean it isn't useful. It does an order of magnitude more compile-time checking than other languages, even if you restrict yourself to the same kind of subset you would use if writing directly in C for a microcontroller, and (in the absence of pragma suppress) will generate full run-time checking, while still being executable on essentially all machines out there. The net effect is a significant boost in productivity, because the Ada compiler and run-time checking are catching more errors, earlier, and providing better feedback as to their cause (rather than simply "bus error" ;-). Things like packages and private types need impose no overhead in the generated C, but can provide great benefits to the speed of debugging and system integration. : KLK -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA