From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-2.9 required=3.0 tests=BAYES_00,NICE_REPLY_A autolearn=ham autolearn_force=no version=3.4.6 Date: Fri, 3 Dec 2021 09:31:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: String Buffer Content-Language: en-GB Newsgroups: comp.lang.ada References: From: ldries46 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Organization: KPN B.V. Path: eternal-september.org!reader02.eternal-september.org!news.uzoreto.com!feeder.usenetexpress.com!tr3.eu1.usenetexpress.com!94.232.116.27.MISMATCH!abe005.abavia.com!abp003.abavia.com!news.kpn.nl!not-for-mail Injection-Date: Fri, 03 Dec 2021 09:31:10 +0100 Injection-Info: news.kpn.nl; mail-complaints-to="abuse@kpn.com" Xref: reader02.eternal-september.org comp.lang.ada:63198 List-Id: Op 2-12-2021 om 20:56 schreef Jeffrey R.Carter: > On 2021-12-02 19:17, Kevin Chadwick wrote: >> >> Unbounded is said to be inefficient because it re-allocates. >> >> In any case avoiding unbounded strings is almost certainly in the >> realm of premature optimisation > "Efficiency" is only meaningful in the context of a project's > quantitative timing requirements: an efficient implementation allows > the project to meet those requirements, while an inefficient > implementation does not. > > In the absence of such context, any claims of "inefficiency" (and > especially blanket claims such as "Unbounded_String is inefficient") > simply demonstrate the speaker's incompetence. > > For an example of context, a decade ago I worked on a soft-real-time > system that made extensive use of Unbounded_String and had no problem > meeting its timing requirements. Unbounded_String was clearly > efficient for that project. Since most projects that would use > Unbounded_String have even less restrictive timing requirements than > that system, it seems likely that Unbounded_String will be efficient > for them, too. > I don't like the word "Efficiency". because what doe it mean. In the time that I started programming 1966/1967 computers were relative slow and small. You did not like any kind of strings because they toke lots of memory and lots of power. Gradually computers started to become faster and bigger (in memory, smaller in size) that meant that string operations also became faster and so use of string operations became more normal. In my opinion programs that need a lot of string manipulation do not need to be very fast because in general there the output is the limiting factor. In most other programs string manipulation is only a small part of the program still becoming faster along with new developments. My statement is that string manipulation does no have to become more efficient because other factors do limit the efficciency of the program much more.