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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,fc52c633190162e0 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!y80g2000hsf.googlegroups.com!not-for-mail From: "kevin cline" Newsgroups: comp.lang.ada Subject: Re: why learn C? Date: 2 Apr 2007 00:43:41 -0700 Organization: http://groups.google.com Message-ID: <1175499821.557815.303270@y80g2000hsf.googlegroups.com> References: <1172144043.746296.44680@m58g2000cwm.googlegroups.com> <1172161751.573558.24140@h3g2000cwc.googlegroups.com> <546qkhF1tr7dtU1@mid.individual.net> <5ZULh.48$YL5.40@newssvr29.news.prodigy.net> <1175215906.645110.217810@e65g2000hsc.googlegroups.com> <1175230352.808212.15550@e65g2000hsc.googlegroups.com> <1175236212.771445.135460@y66g2000hsf.googlegroups.com> <1175308871.266257.77460@e65g2000hsc.googlegroups.com> NNTP-Posting-Host: 76.186.24.40 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1175499823 19518 127.0.0.1 (2 Apr 2007 07:43:43 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 2 Apr 2007 07:43:43 +0000 (UTC) In-Reply-To: <1175308871.266257.77460@e65g2000hsc.googlegroups.com> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: y80g2000hsf.googlegroups.com; posting-host=76.186.24.40; posting-account=Thx6EwwAAAAirqf96i7UdETSL0vfyj5f Xref: g2news1.google.com comp.lang.ada:14725 Date: 2007-04-02T00:43:41-07:00 List-Id: On Mar 30, 9:41 pm, "jimmaureenrog...@worldnet.att.net" wrote: > On Mar 30, 12:30 am, "Case Crab" wrote: > > > On Mar 29, 10:52 pm, "jimmaureenrog...@worldnet.att.net" > > > wrote: > > > On Mar 29, 6:51 pm, "kevin cline" wrote: > > > > > No, what actually happened is that expert C++ developers learned to > > > > use C++ in such a way that those errors can not happen. While it is > > > > possible to write unsafe code in C++, it is also possible to adopt > > > > coding guidelines that makes it easy to find and eliminate unsafe > > > > code, and for most applications, that's quite good enough. > > > > Coding guidelines cannot by themselves prevent any errors. > > > Really? I have found that coding practices can preclude certain > > classes of errors. > > The JSF C++ coding standards are available from several sources on the > web. One link ishttp://www.research.att.com/~bs/JSF-AV-rules.pdf > > The corresponding Ada coding standard is found athttp://software.gsfc.nasa.gov/AssetsApproved/PA2.4.1.1.1.pdf > > > > > > > > For example, > > > the JSF AV C++ Coding Standard, which is intended to limit the unsafe > > > features of C++, contains 221 rules. > > > How many rules distinguish SPARK from the full Ada language? > > > > It is not possible to check > > > 6 million lines of code against 221 rules by hand in any timely or > > > economical manner. > > > I expect that most of the checking can and will be done > > automatically. In any case, I would expect such > > mission-critical code would be inspected, regardless of whether the > > implementation language is C++ or Ada. > > Inspection is the problem. It is inefficient and error prone to > manually inspect 6 million lines of code against 221 rules. > > There is an automated tool for checking the JSF standard. That > tool cannot perform a 100% check either due to the nature of the > rules. > > > > > > The NASA Ada Flight Software coding guidelines contain 14 rules. > > > The intent of both coding standards is to produce software safe enough > > > to use for airborne avionics systems. > > > Interesting that one organization has 221 rules while the other has > > only 14. > > If you analyze the two standards, and understand the two languages, > you > will see that the 221 rules for C++ bring you close to the same safety > level you achieve with the 14 rules for Ada. > > Many of the language features prohibited in the C++ standard simply do > not exist in Ada. This explains the bulk of the differences in the two > standards. For instance: > > AV Rule 20 (MISRA Rule 122) > The setjmp macro and the longjmp function shall not be used. > > Ada has no macros and no equivalent to the longjmp function. > There is no reason to prohibit their use in Ada. > > Similarly: > > AV Rule 29 > The #define pre-processor directive shall not be used to create > inline macros. Inline functions shall be used instead. > Rationale: Inline functions do not require text substitutions > and behave well when called with arguments > (e.g. type checking is performed). > > Ada does allow inline functions and procedures, but has no > language defined macro capability. > > AV Rule 71.1 > A class's virtual functions shall not be invoked from its > destructor or any of its constructors. > Rationale: A class's virtual functions are resolved > statically (not dynamically) in its constructors and > destructor. > > Ada does not provide a direct equivalent to C++ constructors > and destructors. While this may seem a problem to a C++ or > Java programmer, it does have the virtue of not providing > an avenue for the error handled by this rule. > > And the C++ multiple inheritance model provides interesting > opportunities for unsafe code: > > AV Rule 89 > A base class shall not be both virtual and non-virtual in > the same hierarchy. > Rationale: Hierarchy becomes difficult to comprehend and use. > > Do not forget about all the wonders of pointers in C and C++. > For example: > > AV Rule 97 > Arrays shall not be used in interfaces. Instead, the Array > class should be used. > Rationale: Arrays degenerate to pointers when passed as > parameters. This "array decay" problem has long been known to be > a source of errors. > > Ada arrays do not decay to pointers. This problem is unknown in > Ada with or without coding standards. > > > > > > Coding standards can help up to a point. When the coding standards are > > > oppresively complex they cease to help. > > > Compile-time checks can also help, up to a point. But they don't > > solve the whole problem. > > No, run time checks are needed for things that cannot be checked at > compile time. Ada helps is more helpful with run time checks than is > C or C++ due to the automated check writing built by the compilers. > For instance, if you define an integer type with a valid range of > values from -10 to 10, the compiler will perform all necessary > range checking for that type. > > type My_Int is range -10..10; > > You can provide run time checking in any language. In C++ you would > need to define a class for My_Int. Actually, you would define a template class RangedInt, and then write something like: typedef RangedInt<-10,10> My_Int; > The assignment operator would need > to be re-defined to check for the range, and throw an exception when > the range limits are violated. Right. One eight-line class to replicate the Ada ranged integer type. > > C++ provides additional challenges to the definition and checking of > limited range integer types. In C and C++ (and Java) all numeric types > are initialized by default to 0. Not exactly. > What does that do to your program if > 0 is not within the valid range for your type? > The compiler will > simply initialize the data member of your class to an invalid value. > You will need to provide a default constructor to initialize the value > to some valid value, along with the overridden assignment operator. True. The C++ design philosophy was that features would not be added to the language if they could be implemented as library classes. A limited-range integer is a pretty trivial class to write, so there was no need to add it to the language. Also, C++ was designed with the idea that if you didn't need it, you didn't have to pay for it. So variables are not automatically initialized. Modern compilers produce warnings if it is possible for a variable to be used before it has been initialized.