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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,4608b6f4718e680f X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.197.35 with SMTP id ir3mr2367821pbc.6.1336555880901; Wed, 09 May 2012 02:31:20 -0700 (PDT) Path: pr3ni5630pbb.0!nntp.google.com!news2.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: ytomino Newsgroups: comp.lang.ada Subject: Re: Problem in "X (1).Re := X (1).Re + 1" Date: Wed, 9 May 2012 02:29:38 -0700 (PDT) Organization: http://groups.google.com Message-ID: <30097103.0.1336555778034.JavaMail.geo-discussion-forums@pbcow8> References: <13177506.38.1336222539273.JavaMail.geo-discussion-forums@pbtg6> <21452734.731.1336405064187.JavaMail.geo-discussion-forums@ynbv35> <5749033.1275.1336416838264.JavaMail.geo-discussion-forums@pbchd7> <10294366.7.1336426132700.JavaMail.geo-discussion-forums@yngg23> <5209872.2691.1336497260879.JavaMail.geo-discussion-forums@ynlq12> NNTP-Posting-Host: 118.8.128.51 Mime-Version: 1.0 X-Trace: posting.google.com 1336555880 9992 127.0.0.1 (9 May 2012 09:31:20 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 9 May 2012 09:31:20 +0000 (UTC) In-Reply-To: <5209872.2691.1336497260879.JavaMail.geo-discussion-forums@ynlq12> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=118.8.128.51; posting-account=Mi71UQoAAACnFhXo1NVxPlurinchtkIj User-Agent: G2/1.0 Content-Type: text/plain; charset=ISO-8859-1 Date: 2012-05-09T02:29:38-07:00 List-Id: On Wednesday, May 9, 2012 2:14:20 AM UTC+9, Adam Beneschan wrote: > 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 had not made an issue of deallocation, too. At first, I wanted to make calling Reference earlier than calling Constant_Reference in same statement. But it's a kind of "dangling pointer". Real problem is old access value designated to the shared area still alive after copy-on-write. (I'm so thankful to Adam.) > 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. ...m(_ _)m > 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.) Or, making that Constant_Reference also do copy-on-write. Then, an access value designated to shared area does not go out from the container. > 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. Ah, I could not remember it. I feel that perhaps I had read... > I'm going to send something to Ada-Comment about this.