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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,af42f89f2159f3b6
X-Google-Attributes: gid103376,public
From: dewar@cs.nyu.edu (Robert Dewar)
Subject: Re: A note on GNAT 3.05 performance
Date: 1996/06/24
Message-ID: <dewar.835632352@schonberg>#1/1
X-Deja-AN: 162550693
references: <dewar.835245019@schonberg> <4qm21c$qig@mdnews.btv.ibm.com>
 <4qm6kg$1f7a@watnews1.watson.ibm.com>
organization: Courant Institute of Mathematical Sciences
newsgroups: comp.lang.ada
Date: 1996-06-24T00:00:00+00:00
List-Id: <comp.lang.ada>

Norman said

"That was (a small) part of the motivation for access parameters.  If RT
is a record type and you are concerned about the potential inefficiency
of passing RT parameters by copy, and you don't trust your compiler to do
the right thing,..."

This would be more useful if there were not the restriction that an
access parameter must be non-null. There has even been some discussion
of dropping this (rather arbitrary) restriction for interfaced
subprograms. In practice it means that access parameters are not nearly
as useful as they first seem for interfacing, and that you have to use
named access types anyway.

Note also that an access parameter requires a junk acessibility level
hidden parameter to be passed. This at least one hopes is suppressed
for foriegn conventions.