Re: Amount of copying on returned constant objects

["Alex R. Mosteo" <devnull@mailinator.com>]

Randy Brukardt wrote:

> "Pascal Obry" <pascal@obry.net> wrote in message
> news:4676C27D.2050608@obry.net...
>> Or in a more Ada 2005 way:
>>
>>    function Element
>>      (Key : Key_Type) return access constant Element_Type;
> 
> The problem with this is that this access can be saved, and any operation
> on the original container could make it become dangling (and thus any
> further use be erroneous). That is *very* unsafe and virtually impossible
> to detect.

I see. I suspected that would be the reason for its absence. 

> There were a substantial number of people (a group that includes me) that
> want the containers to be safer than using raw access types (because they
> can do checks that would be too tedious to do in hand-written code).
> That's why the containers access-in-place routines use
> access-to-subprograms, because they can have tampering checks that prevent
> the dangling access problem (you get Program_Error if you try to do
> something that could make the element inaccessible). That makes them much
> safer than returning a raw pointer.

Actually I have benefitted from these sanity checks in real code. Too bad we
can have both things...

> We actually spent quite a bit of effort on trying to find a way to secure
> access values returned this way. But it isn't quite possible: even if you
> make them uncopyable; they still can be held onto long enough to
> potentially cause trouble with a renames.
> 
> What really would help would be a way for the container to know when the
> access was destroyed, but there isn't any obvious way to do that in Ada.

I guess then that some reference counting companion type (or maybe making
Cursors tagged and more heavyweight) was discarded because the distributed
overhead?