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-Thread: 103376,25b9eb5c3a89bced X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!t31g2000cwb.googlegroups.com!not-for-mail From: "jimmaureenrogers@worldnet.att.net" Newsgroups: comp.lang.ada Subject: Re: where exactly c++,c fail and Ada gets thru' Date: 23 Apr 2006 22:05:24 -0700 Organization: http://groups.google.com Message-ID: <1145855124.720029.35280@t31g2000cwb.googlegroups.com> References: <1145852356.559455.222600@i39g2000cwa.googlegroups.com> NNTP-Posting-Host: 69.170.89.0 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1145855130 16511 127.0.0.1 (24 Apr 2006 05:05:30 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 24 Apr 2006 05:05:30 +0000 (UTC) User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: t31g2000cwb.googlegroups.com; posting-host=69.170.89.0; posting-account=SqOfxAwAAAAkL81YAPGH1JdBwpUXw9ZG Xref: g2news2.google.com comp.lang.ada:3911 Date: 2006-04-23T22:05:24-07:00 List-Id: Ananth the Boss wrote: > we are developing safety critical software.my seniors say that c and > c++ are not suitable for safety critical software development and ada > is very much safe.NASA aslo uses Ada.at what point c++ or c turns to be > not suitable for devleloping flight software. i may be wrong also. can > any one give some more justifications for telling "ADA is safe" thanks > in advance The Coding Standards for the Joint Strike Fighter http://public.research.att.com/~bs/JSF-AV-rules.pdf give you an idea of the kinds of safety problems recognized in both C and C++. For example, the standard prohibits the use of C-style arrays as function parameters. The problem cited is the degeneration of an array function argument into a pointer. The pointer provides no information about the size of the array it points to. This problem commonly leads to overflowing arrays. Accessing elements beyond the end of an array is always problematic. The C standard explicitly allows one to access one element beyond the end of an array to support common practice in thousands of C programs. The C standard indicates that accessing more than one beyond the end of an array leads to undefined behavior. Polymorphism is one of the heavily used features of C++. Polymorphism intentionally makes it difficult to determine which over-ridden version of a function will be called. Safety critical software standards require the ability to statically determine which function will be called. Polymorphism seriously complicates such static analysis. Neither C nor C++ provides any standard means for detecting overflow or underflow of numeric types. C provides no way to ensure that a numeric type uses only a valid set of values. C++ forces you to define a class wrapping the numeric value. You must also provide all the range checking, resulting in a very inefficient use of programmer time as well as processor time. C++ allows you to define a restricted range integer class as a template. It does not allow you to define a restricted range floating point class because you cannot use floating point values as template parameters. There is no way in C++ to define a template class that achieves the equivalent of: type Normalized_Type is digits 10 range 0.0..1.0; Jim Rogers