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.230.98 with SMTP id sx2mr5411114pbc.1.1336627383557;
        Wed, 09 May 2012 22:23:03 -0700 (PDT)
Path: 
 pr3ni8779pbb.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 22:23:02 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: <32104244.53.1336627382831.JavaMail.geo-discussion-forums@pbcui5>
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>
 <8861140.211.1336552896666.JavaMail.geo-discussion-forums@pbcrz9>
 <jof3fv$40m$1@munin.nbi.dk>
NNTP-Posting-Host: 118.8.128.51
Mime-Version: 1.0
X-Trace: posting.google.com 1336627383 11574 127.0.0.1 (10 May 2012 05:23:03
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Thu, 10 May 2012 05:23:03 +0000 (UTC)
In-Reply-To: <jof3fv$40m$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-09T22:23:02-07:00
List-Id: <comp.lang.ada>

On Thursday, May 10, 2012 9:52:12 AM UTC+9, Randy Brukardt wrote:
> 
> Sure, the containers have some operations where this implementation would be 
> a benefit. But I would guess that those operations would be used very rarely 
> (if ever), so optimizing for them would be a mistake.
> 
> I think this is similar to the usage of the operations in 
> Ada.Strings.Unbounded. There are many operations defined in that package, 
> but most code I've seen only uses a handful of those operations. Optimizing 
> for the other operations is wasted effort.

(This my opinion is unrelated to main subject.)

I could understand it. But I don't want to be satisfied.

Even if Ada.Strings.Unbounded.Replace_Slice *with resizing* is very slow, I will not worry.
However, if Replace_Slice *without resizing* is very slow, I will be angry.
Because, it's getting worse from raw array.
(Of course, exclude the time for memory management. It's main reason to use Unbounded_String.)
And, Vectors is also made to be similar to array. "&" is very popular primitive on array. It should not be worse though it's rarely.

Perhaps, reference counting is exaggerated, such as your saying.
In practice, something that is lighter than reference counting like move semantics (of C++) can satisfy it.

Recently, in GNAT, reference counting is implemented into Unbounded_String.
So, I also expect Vectors.

> That's way I said it might make sense to use this implementation in your own 
> container package, because your usage patterns might be far from typical. 
> (There cannot be a one-size-really-fits-all implementation.)