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.7 with SMTP id we7mr2259795pbc.4.1336552897423;
        Wed, 09 May 2012 01:41:37 -0700 (PDT)
Path: 
 pr3ni5495pbb.0!nntp.google.com!news1.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
From: ytomino <aghia05@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: Problem in "X (1).Re := X (1).Re + 1"
Date: Wed, 9 May 2012 01:41:36 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: <8861140.211.1336552896666.JavaMail.geo-discussion-forums@pbcrz9>
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>
 <joc6nt$ags$1@munin.nbi.dk>
NNTP-Posting-Host: 118.8.128.51
Mime-Version: 1.0
X-Trace: posting.google.com 1336552897 10867 127.0.0.1 (9 May 2012 08:41:37
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Wed, 9 May 2012 08:41:37 +0000 (UTC)
In-Reply-To: <joc6nt$ags$1@munin.nbi.dk>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=118.8.128.51;
 posting-account=Mi71UQoAAACnFhXo1NVxPlurinchtkIj
User-Agent: G2/1.0
Content-Type: text/plain; charset=ISO-8859-1
Date: 2012-05-09T01:41:36-07:00
List-Id: <comp.lang.ada>

On Wednesday, May 9, 2012 7:29:14 AM UTC+9, Randy Brukardt wrote:
> 
> (Note that a copy-on-write implementation is not a good idea for the 
> standard containers for other reasons as well,

> the main one being that the usual uses don't create many copies,

Really?
Ada.Containers.Vectors have some "&" operators.
Many copies may be created when doing X & A & B & C...

Of course, it's ineffective only at reference-counting because appending is one of writing.
More trick is required to use remained area in the capacity.
However, this optimization is possible.
For example, plural containers that are different length are able to share same data area if the areas filled by each container are same.

> so having overhead for that can't be 
> justified. But it should be possible to create a container with that 
> semantics.)