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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,345a8b767542016e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-03-20 09:56:12 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!enews.sgi.com!news-out.spamkiller.net!propagator-la!news-in-la.newsfeeds.com!newsfeed.onecall.net!chcgil2-snf1.gtei.net!news.gtei.net!news.binc.net!kilgallen From: Kilgallen@SpamCop.net (Larry Kilgallen) Newsgroups: comp.lang.ada Subject: Re: memory leakages with Ada? Date: 20 Mar 2002 11:56:04 -0600 Organization: LJK Software Message-ID: References: <3c90af1e@news.starhub.net.sg> <3c91bfa3.1987537@news.demon.co.uk> <3C9629E3.8030109@home.com> <3C9645DD.4020006@mail.com> <3C9659B6.6030204@mail.com> <3C97E496.20404@mail.com> <3C98C195.2030705@home.com> NNTP-Posting-Host: eisner.encompasserve.org X-Trace: grandcanyon.binc.net 1016646966 24946 192.135.80.34 (20 Mar 2002 17:56:06 GMT) X-Complaints-To: abuse@binc.net NNTP-Posting-Date: Wed, 20 Mar 2002 17:56:06 +0000 (UTC) Xref: archiver1.google.com comp.lang.ada:21495 Date: 2002-03-20T11:56:04-06:00 List-Id: In article <3C98C195.2030705@home.com>, "Warren W. Gay VE3WWG" writes: > Hyman Rosen wrote: > >> Larry Kilgallen wrote: >> >>> That code snippet _is_ in the caller's frame. Uppercase is the >>> function being called. The bytes do get copied (obviously) to >>> the caller's frame, but what you see above is the entire syntax >>> for doing that. >> >> Yes, that's exactly what I was trying to say! >> My point was that in the various C techniques, >> the bytes of the result get constructed once, >> and then don't have to be copied as part of >> the function return, whereas returning a String >> in Ada will involve copying the bytes. > > This can be a performance issue if the string is huge. But for > mundane strings, the cost of copying it is much cheaper than the > malloc/free cost, for example. Certainly for huge strings, more attention to performance is required. In programs with which I deal, however, huge data structures are quite outnumbered by tiny data structures. Ignoring performance on the tiny ones leaves more time to worry about performance on the hugh ones.