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,23cf9f1e93744eed X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-08-01 05:58:11 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.uchicago.edu!news-hog.berkeley.edu!ucberkeley!cyclone.bc.net!news-in.mts.net!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Need advice re package organization. References: <3F228F3B.9020203@attbi.com> <3F22F9E9.3040307@attbi.com> <5jn9ivoetll1fu2avn9hmjj6aaa7q7pmjn@4ax.com> <7DbWa.1370$qN3.183518@news20.bellglobal.com> <3F299452.4000802@attbi.com> In-Reply-To: <3F299452.4000802@attbi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 01 Aug 2003 08:51:33 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1059742287 198.96.223.163 (Fri, 01 Aug 2003 08:51:27 EDT) NNTP-Posting-Date: Fri, 01 Aug 2003 08:51:27 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:41123 Date: 2003-08-01T08:51:33-04:00 List-Id: Robert I. Eachus wrote: > Warren W. Gay VE3WWG wrote: > >> That appears to accomplish the end result. However, this >> design pays a price in allocating and freeing an additional >> [sub]object. >> >> For some designs this would be acceptable, but not where >> you have many instances of the object, where the price >> of allocate/free is too heavy. > > > No, remember the access all. The values of the actual objects need not > be on the heap, or could be on the heap but not individually allocated > For example, I have a package that implements sparse matrices, as linked > lists of rows and columns. Very messy and the allocation overhead might > make it useless if the package didn't just grab chunks of heap and > manage them as 10,000 separate nodes. This way, creating an array takes > time proportional to the number of non-zero elements, but much faster > than allocating each element, and freeing an array takes time > proportional to the number of non-zero columns. And that is fine if you are instantiating all of those objects in one fell swoop, or managing a pool of such. But _all_ of these are "work-arounds" to the original problem. All of these work arounds take you away from the original problem at hand. Others will also argue that other environments do not require these work-arounds, either. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg