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,64b29dfa2220a59f X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!m37g2000prh.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Reserve_Capacity for Unbounded_String? Date: Mon, 23 Jul 2007 08:07:18 -0700 Organization: http://groups.google.com Message-ID: <1185203238.701948.307410@m37g2000prh.googlegroups.com> References: <1185134043.892012.217560@n2g2000hse.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1185203239 12644 127.0.0.1 (23 Jul 2007 15:07:19 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 23 Jul 2007 15:07:19 +0000 (UTC) In-Reply-To: <1185134043.892012.217560@n2g2000hse.googlegroups.com> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: m37g2000prh.googlegroups.com; posting-host=66.126.103.122; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Xref: g2news1.google.com comp.lang.ada:16553 Date: 2007-07-23T08:07:18-07:00 List-Id: On Jul 22, 12:54 pm, Maciej Sobczak wrote: > Why there is no Reserve_Capacity for Unbounded_String? > Sounds like a natural idea to me. > > How to emulate it? > > The following seems to work fine: > > declare > S : Unbounded_String; > My_Capacity : constant := 1000; > begin > S := To_Unbounded_String (My_Capacity); > Delete (Source => S, From => 1, Through => My_Capacity); > -- ... > end; > > "Seems to work fine" means that after the above two operations the > string is logically empty, but the subsequent appends run faster > (which is actually the original motivation). > > Is this a reasonable approach if performance is of concern? I sure wouldn't count on this. I don't know what compiler you're using or how it implements Unbounded_String; but just based on what I know about how this package *might* be implemented and about the suggested implementation in the Rationale, the performance improvements you're seeing could be just an accident. (One test: try doing something like "Intp := new Integer;" after each append. If the Delete actually deallocates memory, and a piece of that memory could be reused by a "new Integer" allocation, you may get very different performance results than if the deallocated memory is never reused except by new appends. Here, though, I'm just guessing, since as I said I have no idea how Unbounded_Strings is implemented.) I'm with Jeff here: you may need an Unbounded_Strings package tailored to your specific needs. It just isn't possible to write a package that will achieve the best performance for all programs that might want to use it; even a simple idea like "Reserve_Capacity" could introduce some implementation overhead that might be unwelcome in programs that wouldn't benefit from that feature. -- Adam