Re: Visibility of Indexing aspects

["Dan'l Miller" <optikos@verizon.net>]

On Friday, August 3, 2018 at 3:56:59 PM UTC-5, Randy Brukardt wrote:
> "Dan'l Miller" <optikos@verizon.net> wrote in message 
> news:dc0f1491-0e8c-43c5-a78f-e32d59df5f03@googlegroups.com...
> On Thursday, August 2, 2018 at 3:31:18 PM UTC-5, Randy Brukardt wrote:
> ...
> >> 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.
> 
> >In the above-mentioned case of prohibiting 4 of the 5, the programmer
> >seeks not performance improvement.
> 
> Better programmers don't worry about performance all of the time, but 
> *everyone* has to worry about it some of the time.
> 
> >The programmer seeks proscribing the retention of certain* data and
> >structure by the outside-of-this-package world-topics which the
> >outside-of-this-package world has no business retaining or using directly
> >or abusing, ...
> 
> This is an utterly false statement; there is plenty of reasons to use the 
> various parts directly; specifically for improved performance. Almost 
> everything used in the indexing operations previously existed in the Ada 
> 2005 version of the container, after all.
> 
> So, since you're starting with a pair of fallicies, the rest of what you 
> have to say is irrelevant. ("if False then anything" is a true [and useless] 
> statement.)
> 
>                                             Randy.

Ummmmmmmmm, what is so incredibly “expensive” about Element => Self.Data(Index)'Access in OP?  You seem to be making some sort of gross inefficiency point, but the core piece of this conversation is OP's seminal-referent library •forcing• the usage of only Element => Self.Data(Index)'Access, which is in effect ‘give me the von Neumann address of an element in the array (as an alias)’.  I am a little confused how obtaining the von Neumann address of an element in an array causes gross inefficiency; it seems like such a straight-forward lightweight operation:  an integer calculated by mere garden-variety pointer arithmetic of base-address plus offset.

I am a little confused how even the “(as an alias)” part causes gross inefficiency in execution time expended.  It might complicate drastically the •release• of the array by not easily knowing when all of the elements have been de-aliased, but when to late-release the array is not a gross inefficiency of execution time expended; it is mere delay in time pessimistically until certainty has been reached that all the aliases' lifetimes have ended.  But even that meticulous lifetime tracking seems trivial:  reference count the number of aliases-to-elements anywhere in the array; don't dealloc the entire array until the alias-lifetime reference count returns to zero.