Re: Visibility of Indexing aspects

["Randy Brukardt" <randy@rrsoftware.com>]

(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.