From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,MSGID_SHORT
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 12 Feb 91 19:13:20 GMT
From: seas.gwu.edu!mfeldman@uunet.uu.net  (Michael Feldman)
Subject: LRM 4.1.3 paragraphs 17-19
Message-ID: <2711@sparko.gwu.edu>
List-Id: <comp.lang.ada>

In article <631.27b781ac@vger.nsu.edu> g_harrison@vger.nsu.edu ((George C. Harrison) Norfolk State University) writes:
>
>What do you mean by "_better_ optimized code?"  If you mean what constructs
>_might_ lead the compiler to produce more optimized code than the "Brute Force"
>methods like in the example of this original posting, I'd agree with your
>assessment below.  "Optimized" to programmers generally means what the compiler
>(and often the linker) does to make a faster, smaller executable.  These
>constructs, I believe, leave their implementations better open to
>these optimizations.
>
>> IMHO aggregates, universal assignment (i.e.
>> assignment operator for structured types) and universal equality are three
>> such things. 
That is what I meant, inarticulately though I may have written it. The point is
that many Ada programmers do not focus on some of these constructs, which not
only save their own time and make their code clearer, but may make their
code faster as well. I see a lot of code written with the brute force
structures used in older languages - this is a shame because the Ada is not
only not as "good" but also potentially not as fast.
>
>The other kind of optimization is that which saves the programmers time and
>makes him/her more effective.  These include generics, separate compilation,
>exceptions, overloading, and other supports for abstraction.  The problem is
>that this kind of programmer optimization does not necessarily lead to
>executable optimization.  
>
Well, sure. I certainly wouldn't argue against using the real abstraction
power of Ada. I was really trying to make a different point, namely that
even if one sticks to the "classical" part of Ada - the inner, program-
level syntax, one can potentially get some nice optimization just by
using the language well, without doing tricks. I am still astounded by
the number of programmers who know all about (or think they know all about)
packages, generics, renaming declarations, etc., and who continue to
assert that Ada executables are _necessarily_ slow. They are actually pleased 
when I point out the "little" ways in which Ada can be faster.
They say "hmmmm... I never focused on that..."

Mike