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!news2.google.com!news.glorb.com!newscon02.news.prodigy.net!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Reserve_Capacity for Unbounded_String? Date: Mon, 23 Jul 2007 16:30:26 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <1185134043.892012.217560@n2g2000hse.googlegroups.com> <1185218940.794004.249540@57g2000hsv.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1185222627 14989 192.74.137.71 (23 Jul 2007 20:30:27 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Mon, 23 Jul 2007 20:30:27 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:RPRw4EAQjRc+339QsNnyLmbfNyg= Xref: g2news1.google.com comp.lang.ada:16572 Date: 2007-07-23T16:30:26-04:00 List-Id: Maciej Sobczak writes: > On 22 Lip, 23:32, Robert A Duff wrote: > >> > Why there is no Reserve_Capacity for Unbounded_String? >> >> Probably for historical reasons. > > Would introducing it break any existing code? Only in rare cases. For ex., if you had a type called Reserve_Capacity in an unrelated package, and you had "use" on that one and also on unbounded strings, the code would now be illegal. >> > declare >> > S : Unbounded_String; >> > My_Capacity : constant := 1000; >> > begin >> > S := To_Unbounded_String (My_Capacity); >> >> I would write >> >> To_Unbounded_String (Length => My_Capacity); >> >> to make it clear which To_Unbounded_String you're calling. > > Yes. I try to follow the "rule" that names associations should be used > for any subprogram call with more than one parameter. Well, that's close, but not quite the right rule. For example, "+" on integers has two parameters, but I would say X+Y rather than "+"(Left => X, Right => Y). I don't have a well-defined rule, but I like to use named notation often. I think perhaps the designer of the subprogram should decide whether named notation is appropriate, and all callers have to obey. But that's a language design issue, not an Ada issue. >...I've never > considered hardening this rule for overloaded subprograms. > >> > "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). >> >> How much faster (I'm curious)? > > This of course depends on what is the ration between allocations and > reservations in a given test. > > Here: > > with Ada.Strings.Unbounded; > procedure String_Test is > begin > for I in 1 .. 10000 loop > declare > S : Ada.Strings.Unbounded.Unbounded_String; > use Ada.Strings.Unbounded; > begin > -- S := Ada.Strings.Unbounded.To_Unbounded_String (10000); > -- Ada.Strings.Unbounded.Delete (S, 1, 10000); > for J in 1 .. 10000 loop > Ada.Strings.Unbounded.Append (S, 'A'); > end loop; > end; > end loop; > end String_Test; > > On my machine and with option -O2 uncommenting the two lines makes a > difference between 1.86s and 1.43s, which is about 20% gain. Interesting. Thanks for posting the measurements. >...Depending > on a situation it might or might not be worth the hassle (the hassle > is in determining the correct reservation size - and if we can know it > fully in advance, then maybe there is no point in using unbounded at > all). Good point. If you know the max size, the Bounded (or just plain String) is appropriate. But if you know the max "typical" size, but that you still want it to work for atypical sizes, then this sort of thing seems reasonable. As others have pointed out, it depends on the implementation. But that's always true about efficiency -- if you care about efficiency, then the abstraction leaks. - Bob