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!news4.google.com!newsfeed.stanford.edu!sn-xit-03!sn-xit-08!sn-post-01!supernews.com!corp.supernews.com!not-for-mail
From: CTips <ctips@bestweb.net>
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: Sat, 12 Mar 2005 12:46:11 -0500
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <1136ao15lb0go9c@corp.supernews.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.5) Gecko/20041217
X-Accept-Language: en-us, en
MIME-Version: 1.0
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> <ow2Yd.21162$7U5.4617@fe04.lga>
 <opsnfw9nx75afhvo@localhost> <d0qiah$ep71@cui1.lmms.lmco.com>
 <pan.2005.03.11.18.01.45.684764@linuxchip.demon.co.uk.uk.uk>
 <1110569032.207770@athnrd02> <d0st28$ep65@cui1.lmms.lmco.com>
 <1110607809.837000@athnrd02> <1110608948.651588@athnrd02>
 <1110609321.686344@athnrd02> <V4BYd.89118$H05.42532@twister.nyroc.rr.com>
In-Reply-To: <V4BYd.89118$H05.42532@twister.nyroc.rr.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@supernews.com
Xref: g2news1.google.com comp.lang.ada:9242 comp.lang.c++:45309
 comp.realtime:1374 comp.software-eng:4934
Date: 2005-03-12T12:46:11-05:00
List-Id: <comp.lang.ada>

REH wrote:

> "Ioannis Vranos" <ivr@remove.this.grad.com> 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.