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,FREEMAIL_FROM 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!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Sat, 12 Mar 2005 12:51:23 -0600 Date: Sat, 12 Mar 2005 13:51:34 -0500 From: Jeff C User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 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) 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> In-Reply-To: <1136ao15lb0go9c@corp.supernews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <1ISdnVuSYZy2p67fRVn-2Q@comcast.com> NNTP-Posting-Host: 24.147.74.171 X-Trace: sv3-a215uHxEQoDFvkNqZZnbsAUoq4krc2PvLIECNerIUhk6WwBAqlXvk+zeEJlntSfoRhtetxml1HclbzW!rWPrPtUr1QFxbYx9hj3lGmUGbvgzu4RA4XVic7jAImea0cyvze/gn7PbrvEQ8w== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.lang.ada:9245 comp.lang.c++:45316 comp.realtime:1378 comp.software-eng:4941 Date: 2005-03-12T13:51:34-05:00 List-Id: CTips wrote: > REH wrote: > >> "Ioannis Vranos" wrote in message >> news:1110609321.686344@athnrd02... >> >> >>>> Myself thinks though that this whole range specialisation thing is >>>> non-sense for regular application programming at least. >>> >>> >>> >>> Indeed. :-) >>> >>> >> >> Not all of us do "regular application programming." I write >> mission-critical systems. In such an environment, it is non-sense NOT >> to define ranges for data types that have them. I would rather it >> "failed loudly" when a variable strayed out of range and raised an >> exception I can recover from, then continuing to run, causing unknown >> or undefined behavior. >> > > 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. > > 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. > > 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. Of course one could insert manual checks for those cases as well and it is certainly possible to disable the automatic checks (in fact, I'd argue a bit with some others about the "cheapness" of these checks. It certainly varies from compiler to compiler and program to program but in a moderate sized set of applications (~150K SLOC) I have measured the penalty as high as 10-15%.). The automatic checks are available. You can use them just during development and disable for production or if you can live with them, then you can leave them on during production..But, arguing that it is bad for the language to provide for them because it might not be what you want is like arguing that the C++ standard should not include any references to floating point since sometimes you have a processor that does not have an FPU and then you'd feel more comfortable rolling your own floating point.