Re: Problem in "X (1).Re := X (1).Re + 1"

[Adam Beneschan <adam@irvine.com>]

On Monday, May 7, 2012 6:14:42 PM UTC-7, Randy Brukardt wrote:
> "Adam Beneschan" wrote in message 
> news:10294366.7.1336426132700.JavaMail.geo-discussion-forums@yngg23...
> On Monday, May 7, 2012 11:53:58 AM UTC-7, ytomino wrote:
> > On Tuesday, May 8, 2012 12:37:44 AM UTC+9, Adam Beneschan wrote:
> ...
> >So it looks to me like the method you suggest shouldn't be allowed, even in 
> >your own container,
> > since it would make it impossible to implement Constant_Reference 
> > correctly.
> 
> It seems to me that his implementation is wrong, since Constant_Reference 
> creates a reference, so it should be impossible for something else to 
> "deallocate" the reference at the same time. (I'm talking about in a 
> hand-created container,  I don't think this implementation would be 
> legitimate for Vectors - although I'm not certain). That probably means that 
> Constant_Reference would have to increase the reference count when it is 
> created and decrease it when it is destroyed (specifically the reason why 
> these return record types with discriminants rather than just a bare access 
> value). If that's done, his original example is fine.

I'm not so sure.  If I understand the issue correctly, the problem isn't deallocation.  The problem occurs when two separate vector elements (whether they are elements of different vectors or of the same vector) share the same location temporarily; but later, the location of one of them moves, so that they no longer share the same location.  When that happens, any Constant_Reference that was previously applied to the element that has moved is no longer valid.  I don't see how having Constant_Reference increase a reference count solves the problem. (It would prevent a deallocation, but I think this is a problem that occurs before there is any deallocation.)  I may be misunderstanding what the OP is trying to accomplish; my understanding is based on the term "copy-on-write", but he didn't provide any details, and I had to look up what it meant since I wasn't familiar with the term.  Anyway, I think that a user-defined container would have the same problem as the language-defined container.  (It seems like, for a user-defined container, making Constant_Reference private would help.  Then it could still be used for user-defined indexing operations, while, I think, preventing callers from creating Constant_Reference_Type objects that could still exist when the elements that they refer to are relocated.)

In fact, looking into this further, I think there's a problem with the AARM in this regard.  A.18.2(254.a), which was from Ada 2005, says "an implementation that avoided copying until one of the containers is modified would be allowed".  It seems to me that this is no longer true.  I'm going to send something to Ada-Comment about this.

                           -- Adam