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.204.132.81 with SMTP id a17mr107241bkt.4.1337126469935;
        Tue, 15 May 2012 17:01:09 -0700 (PDT)
MIME-Version: 1.0
Path: 
 e27ni6548bkw.0!nntp.google.com!news2.google.com!goblin1!goblin.stu.neva.ru!news.tornevall.net!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Problem in "X (1).Re := X (1).Re + 1"
Date: Tue, 15 May 2012 19:01:06 -0500
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <jouqo4$lba$1@munin.nbi.dk>
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>
 <jo9s26$scj$1@munin.nbi.dk>
 <5209872.2691.1336497260879.JavaMail.geo-discussion-forums@ynlq12>
 <30097103.0.1336555778034.JavaMail.geo-discussion-forums@pbcow8>
 <jof3r1$475$1@munin.nbi.dk>
 <16249910.1154.1336624012153.JavaMail.geo-discussion-forums@pbyy9>
 <josrui$ka5$1@munin.nbi.dk>
 <29152338.116.1337113067360.JavaMail.geo-discussion-forums@pbcjt7>
NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net
X-Trace: munin.nbi.dk 1337126468 21866 69.95.181.76 (16 May 2012 00:01:08 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Wed, 16 May 2012 00:01:08 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Date: 2012-05-15T19:01:06-05:00
List-Id: <comp.lang.ada>

"ytomino" <aghia05@gmail.com> wrote in message 
news:29152338.116.1337113067360.JavaMail.geo-discussion-forums@pbcjt7...
...
> 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.

Yes, of course.

> 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.

Quite right. But my point was that the examples you showed would almost 
certainly fail the tampering check in the Standard containers (*any* correct 
implementation) - so long as you have a valid pointer to an element, you 
cannot tamper with the container (tampering prevents certain types of 
modifications). So those examples would raise an exception, and the 
reference counting problems would never arise (because the modification is 
prevented).

The tampering check allows a wide variety of ways to manage the elements of 
a container, but probably not *every* possible way. And it should be obvious 
that any time you have a pointer into part of a container, you have to be 
very careful about what operations are allowed while that pointer exists. 
That might prevent some sorts of implementations, but it is the nature of 
pointers. (If that's really a problem for a custom container, don't use 
them!).

                                Randy.