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,703c4f68db81387d X-Google-Thread: 109fba,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid109fba,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!newscon02.news.prodigy.com!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng Subject: Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada) Date: 12 Mar 2005 14:14:32 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <42309456$1@news.broadpark.no> <1110569032.207770@athnrd02> <1110607809.837000@athnrd02> <1110608948.651588@athnrd02> <1110609321.686344@athnrd02> <1136ao15lb0go9c@corp.supernews.com> NNTP-Posting-Host: shell01-e.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1110654873 32588 69.38.147.31 (12 Mar 2005 19:14:33 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sat, 12 Mar 2005 19:14:33 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:9250 comp.lang.c++:45321 comp.realtime:1382 comp.software-eng:4945 Date: 2005-03-12T14:14:32-05:00 List-Id: CTips writes: > Thats another problem with Ada's run-time checking. If you're using it > in an environment where the hardware may "fail" [e.g. alpha particles > randomizing memory], the checks are quite often in the wrong place. That's like saying "another problem with my refrigerator is that it doesn't cook food". Ada's run-time checking is not intended to deal with hardware failures of this nature. Neither are if statements in Ada or C++. > For example, look at the Ada equivalent of the following code. > typedef enum {0, 1, 2, 3} four_val; > four_val x; > > x = (four_val) some_int; > .... > assert( x < 4); > > The compiler will drop in a check at the cast to ensure that the wrong > value is not getting stored into x. Then, it will proceed to eliminate > the check that x < 4, because it knows that 0..3 are the only legal > values of x. However, if there is a hardware bug, the value of x will > get changed between the definition point and the use point. That could happen whether or not you have automatic run-time checks. And in the above, there is no guarantee that x<4 in the code following the assert -- the alpha particle could hit just after the assertion. Just as in "if (X < 4) { ... X ... }", the second reference to X might produce 17, if hardware can fail. > When bringing up hardware, I like to have a little more control over > where the run-time checks are going to be placed. This is another niche > situtation in which the compiler's "automatic" checking does the wrong > thing. You have no such control in either language under discussion. Compilers can and do optimize code based on the assumption that the hardware is perfect. If you don't like that, you have to write in assembly language, or dump out the assembly language and make sure it does what you want. Or use redundant hardware, or wrap the thing in lead, or any number of other techniques that have nothing whatsoever to do with Ada or C++ or run-time checking! - Bob