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-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,52fd60a337c05842
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2002-06-14 05:18:12 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!newsfeed-west.nntpserver.com!hub1.meganetnews.com!nntpserver.com!DirecTVinternet!DirecTV-DSL!news-out.spamkiller.net!propagator2-maxim!propagator-maxim!news-in.spamkiller.net!feed.newsfeeds.com!newsfeed.onecall.net!chcgil2-snf1.gtei.net!news.gtei.net!news.binc.net!kilgallen
From: Kilgallen@SpamCop.net (Larry Kilgallen)
Newsgroups: comp.lang.ada
Subject: Re: ada paper critic
Date: 14 Jun 2002 06:58:09 -0600
Organization: LJK Software
Message-ID: <yDQOeSu3jWKl@eisner.encompasserve.org>
References: <aebegp$5cpo1$1@ID-100557.news.dfncis.de>
 <aebgq8$5goi4$1@ID-100557.news.dfncis.de> <3D095F70.8090001@telepath.com>
 <dale-7114C2.14352714062002@its-aw-news.its.rmit.edu.au>
NNTP-Posting-Host: eisner.encompasserve.org
X-Trace: grandcanyon.binc.net 1024055890 1829 192.135.80.34 (14 Jun 2002
 11:58:10 GMT)
X-Complaints-To: abuse@binc.net
NNTP-Posting-Date: Fri, 14 Jun 2002 11:58:10 +0000 (UTC)
Xref: archiver1.google.com comp.lang.ada:25934
Date: 2002-06-14T06:58:09-06:00
List-Id: <comp.lang.ada>

In article <dale-7114C2.14352714062002@its-aw-news.its.rmit.edu.au>, Dale Stanbrough <dale@cs.rmit.edu.au> writes:
> Ted Dennison wrote:
> 
>> But if you want real numbers that mean something, get the compilers you 
>> would use if you were to pick that language, and compare their output 
>> for the types of code you will be generating. Speed has way more to do 
>> with the effort your compiler writers put into optimization than with 
>> the language.
> 
> async abort is one counter example of this. The definition is such 
> that programs take a hit in efficiency (or so i have read in this 
> newsgroup).

> ...and doesn't the fact that the only way to attach information
> to an exception is via a string, requiring conversions  to/from
> the appropriate format just to find out what -really- went wrong?

The spirit of exception processing is that it is supposed to be done
on an infrequent basis.  Performing giant sort in Cobol is more costly
than a simple multiplication in the same language.