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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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.241.98 with SMTP id wh2mr3480303pbc.7.1336497268231; Tue, 08 May 2012 10:14:28 -0700 (PDT) Path: pr3ni3071pbb.0!nntp.google.com!news1.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Problem in "X (1).Re := X (1).Re + 1" Date: Tue, 8 May 2012 10:14:20 -0700 (PDT) Organization: http://groups.google.com Message-ID: <5209872.2691.1336497260879.JavaMail.geo-discussion-forums@ynlq12> 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> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 X-Trace: posting.google.com 1336497261 12211 127.0.0.1 (8 May 2012 17:14:21 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 8 May 2012 17:14:21 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-05-08T10:14:20-07:00 List-Id: On Monday, May 7, 2012 6:14:42 PM UTC-7, Randy Brukardt wrote: > "Adam Beneschan" wrote in message=20 > 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=20 > >your own container, > > since it would make it impossible to implement Constant_Reference=20 > > correctly. >=20 > It seems to me that his implementation is wrong, since Constant_Reference= =20 > creates a reference, so it should be impossible for something else to=20 > "deallocate" the reference at the same time. (I'm talking about in a=20 > hand-created container, I don't think this implementation would be=20 > legitimate for Vectors - although I'm not certain). That probably means t= hat=20 > Constant_Reference would have to increase the reference count when it is= =20 > created and decrease it when it is destroyed (specifically the reason why= =20 > these return record types with discriminants rather than just a bare acce= ss=20 > 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 de= allocation. The problem occurs when two separate vector elements (whether = they are elements of different vectors or of the same vector) share the sam= e location temporarily; but later, the location of one of them moves, so th= at 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 referen= ce 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 b= ased 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 fr= om 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 implemen= tation that avoided copying until one of the containers is modified would b= e allowed". It seems to me that this is no longer true. I'm going to send= something to Ada-Comment about this. -- Adam