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.223.40 with SMTP id qr8mr3552038pbc.0.1337119978461;
        Tue, 15 May 2012 15:12:58 -0700 (PDT)
Path: 
 pr3ni2934pbb.0!nntp.google.com!news2.google.com!goblin2!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Problem in "X (1).Re := X (1).Re + 1"
Date: Tue, 15 May 2012 23:12:56 +0100
Organization: A noiseless patient Spider
Message-ID: <m2zk99855j.fsf@nidhoggr.home>
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>
Mime-Version: 1.0
Injection-Info: mx04.eternal-september.org;
 posting-host="Pd4gCuG8QV/d3K7tc8x0Wg";
	logging-data="31252"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18IXwm8wKYaCFyGCL+qP9UAxCiHjRi1UVY="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (darwin)
Cancel-Lock: sha1:F3e12/mB07m/AZ0Q7AMgONpBa6k=
	sha1:j4USXntogweFa6+gRrCvD9d6BqQ=
Content-Type: text/plain; charset=us-ascii
Date: 2012-05-15T23:12:56+01:00
List-Id: <comp.lang.ada>

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "ytomino" <aghia05@gmail.com> wrote in message 
> news:30097103.0.1336555778034.JavaMail.geo-discussion-forums@pbcow8...
> ...
>> 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.)
>
> 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).
>
> So the act of assigning a "Constant_Reference" as Adam did is to
> "lock" the container from [most] modification for a long time. That
> might be a problem for the program, but it can't cause the container
> to become corrupt.

Fair enough, but the copy-on-write scheme means that simply updating a
value in an element may be "tampering" - which I'm fairly sure it isn't
now (A.18.2(97)).

There seem to be new opportunities for error here.

I suppose that an implementation that used copy-on-write for the
standard containers would have to warn users that any use of Reference
or Constant_Reference would be liable to result in Program_Error in
unexpected places.

Note, I'm not saying this is a bad thing; I think it's exactly the right
thing (and probably a good reason not to implement the standard
containers like this).