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.241.98 with SMTP id wh2mr3225760pbc.7.1337113179766; Tue, 15 May 2012 13:19:39 -0700 (PDT) Path: pr3ni2635pbb.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: Tue, 15 May 2012 13:17:47 -0700 (PDT) Organization: http://groups.google.com Message-ID: <29152338.116.1337113067360.JavaMail.geo-discussion-forums@pbcjt7> 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> <30097103.0.1336555778034.JavaMail.geo-discussion-forums@pbcow8> <16249910.1154.1336624012153.JavaMail.geo-discussion-forums@pbyy9> NNTP-Posting-Host: 114.145.71.195 Mime-Version: 1.0 X-Trace: posting.google.com 1337113179 26855 127.0.0.1 (15 May 2012 20:19:39 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 15 May 2012 20:19:39 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=114.145.71.195; posting-account=Mi71UQoAAACnFhXo1NVxPlurinchtkIj User-Agent: G2/1.0 Content-Type: text/plain; charset=ISO-8859-1 Date: 2012-05-15T13:17:47-07:00 List-Id: On Tuesday, May 15, 2012 3:09:18 PM UTC+9, Randy Brukardt wrote: > "ytomino" wrote in message > news:16249910.1154.1336624012153.JavaMail.geo-discussion-forums@pbyy9... > > On Thursday, May 10, 2012 9:58:04 AM UTC+9, Randy Brukardt wrote: > >> > >> This reminds me of something I forgot: The beauty of > >> Constant_Reference/Reference in the standard containers is that there > >> cannot > >> be a dangling pointer (assuming no Unchecked programming is involved). > >> These > >> are tampering events so long as the pointer still exists, and thus is it > >> impossible to modify the container (attempts to do so will raise > >> Program_Error). > > > > I agree, generally. > > > > Only in the cases of my and Adam's sample code, we have hoped that they > > work through > >with reference-counting or no reference-counting. So any exceptions are > >unsuitable. > > "Unsuitable"? Doing dangerous things ought to be prevented; that's the point > of the exceptions. And keeping uncontrolled pointers into a container that > might be modified is one of those dangerous things. It took a *lot* of > convincing that it could be possible to safely allow pointers at container > elements. > > Also note that not all container modifications are prevented, mostly ones > that would cause trouble (although this is rather conservative). > > Obviously, you can write your own container that allows any unsafe things > you want, but that's not possible with the Standard containers. > > Randy. Sorry, I can't understand what is your argument, and probably my words are lacking again. If a Standard container that's implemented A.18.2(254.a) is existing, should not it behave similarly to the normal version (no sharing version) Standard container? I think yes. Naturally error checkings have to be inserted. But, in the cases that the normal version container does not raise any exceptions, the sharing version should try to make coherence by doing a trick at its hidden side, instead of raising a exception. I feel that it has been an implicit promise.