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,XPRIO
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Visibility of Indexing aspects
Date: Thu, 2 Aug 2018 15:31:15 -0500
Organization: JSA Research & Innovation
Message-ID: <pjvpmk$u33$2@franka.jacob-sparre.dk>
Injection-Date: Thu, 2 Aug 2018 20:31:17 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk;
 posting-host="rrsoftware.com:24.196.82.226";
	logging-data="30819"; mail-complaints-to="news@jacob-sparre.dk"
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246
Xref: reader02.eternal-september.org comp.lang.ada:54023
Date: 2018-08-02T15:31:15-05:00
List-Id: <comp.lang.ada>

(Sorry about breaking the thread, the reference headers have gotten too long 
for the news server to accept them. - RLB)

"Dan'l Miller" <optikos@verizon.net> wrote in message
news:ebf25374-fbd0-4239-9f24-1496b7699f74@googlegroups.com...
>On Friday, July 27, 2018 at 5:06:00 PM UTC-5, Randy Brukardt wrote:
>> "Dan'l Miller" wrote in message
>> news:71ab145a-83fd-46af-81c3-fe72c67c6897@googlegroups.com...
>> > ...(even when the programmer considers 4 of them as a bad idea) ...
>>
>> A pretty inflexible programmer if you ask me. This is the same sort of
>> programmer that then complains that the performance of indexing isn't
>> good
> enough, because they are triggering all of this expensive mechanism rather
>> than directly doing something simple.
>
>Expensive?  Gee, I would think that precisely the same machine code
>verbatim
>would be generated for each of the following syntactic variants of the one
>and
>only same semantic meaning:
>
>Find (IB,"pear").Data.all := Element'(...); -- Traditional call
>IB.Find ("pear").Data.all := Element'(...); -- Call of prefixed view
>IB.Find ("pear") := Element'(...); -- Implicit dereference (see 4.1.5)
>IB ("pear") := Element'(...); -- Implicit indexing and dereference
>IB ("pear").Data.all := Element'(...); -- Implicit indexing only

Surely, and all 5 of these are quite expensive, because the use of Reference
(which is implicit in all 5 of these!) requires returning (and thus creating
and destroying) a controlled, composite object. [GNAT has a non-standard way
of eliminating the controlled part, which of course makes the use of the
containers substantially less safe.]

My point is that a programmer that truly cares about performance (and
hopefully that will only be concerning in a few critical situations) would
avoid using Reference at all if there isn't a need to update-in-place part
of the element. That is, one would still use the underlying operations, but
individually rather than all automatically as part of a set.

                          Randy.