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.191.225 with SMTP id hb1mr6370783pbc.5.1336406556256;
        Mon, 07 May 2012 09:02:36 -0700 (PDT)
Path: 
 pr3ni14909pbb.0!nntp.google.com!news1.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
From: Adam Beneschan <adam@irvine.com>
Newsgroups: comp.lang.ada
Subject: Re: Problem in "X (1).Re := X (1).Re + 1"
Date: Mon, 7 May 2012 08:37:44 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: <21452734.731.1336405064187.JavaMail.geo-discussion-forums@ynbv35>
References: <13177506.38.1336222539273.JavaMail.geo-discussion-forums@pbtg6>
NNTP-Posting-Host: 66.126.103.122
Mime-Version: 1.0
X-Trace: posting.google.com 1336406556 3518 127.0.0.1 (7 May 2012 16:02:36
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Mon, 7 May 2012 16:02:36 +0000 (UTC)
In-Reply-To: <13177506.38.1336222539273.JavaMail.geo-discussion-forums@pbtg6>
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-07T08:37:44-07:00
List-Id: <comp.lang.ada>

On Saturday, May 5, 2012 5:55:39 AM UTC-7, ytomino wrote:
> This is a thought experiment.
>=20
> First, in RM 4.1.6:
>=20
> * when the generalized_indexing is used within a primary where a name den=
oting a constant is permitted.
>=20
> This means
>=20
> declare
>    package V is new Vectors (Complex);
>    X : V.Vector;
> begin
>    X (1).Re :=3D X (1).Re + 1;
> end;
>=20
> is interpreted as
>=20
> declare
>    package V is new Vectors (Complex);
>    X : V.Vector;
> begin
>    Reference (X, 1).Element.all.Re :=3D Constant_Reference (X, 1).Element=
.all.Re + 1;
> end;
>=20
> Is this OK?

No.  But if you change the 1 to 1.0 then I think it will be OK.

>=20
> If this is the truth, and if Vectors is implemented by reference-counting=
.
> (I don't know copy-on-write is permitted in Ada.Containers.Vectors. Other=
wise, please assume my original container like Vectors.)
>=20
> Well then...
> May a next eval-order problem be caused or not?
>=20
> 1. eval "Constant_Reference (X, 1)" =3D> get an accessor pointing to shar=
ed data. (reference counter > 1)
> 2. eval "Reference (X, 1)" =3D> do copy-on-write, and get an accessor poi=
nting to new unshared data.
> 3. eval ".Element.all.Re" in right side =3D> access *old* shared data. <-=
 !!!!
> 4. eval ".Element.all.Re" in left side =3D> access new data.
> 5. eval + 1 =3D> calculate old data + 1.
> 6. eval assignment =3D> store the result into new data.

I'm not yet really familiar with the ins and outs of user-defined reference=
s and user-defined indexing.  But my guess is that the phrase in A.18.2(147=
.17) that says "Reference returns an object whose discriminant is an access=
 value that designates the element designated by Position" means that Refer=
ence can't return an object whose discriminant designates a *copy* of the e=
lement.  If I understand your question correctly, this means that the scena=
rio you're concerned about can't happen.

But, as I said, I'm not completely familiar with all the issues involved.

                       -- Adam