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-07-31 15:13:02 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!sccrnsc02.POSTED!not-for-mail
Message-ID: <3F299452.4000802@attbi.com>
From: "Robert I. Eachus" <rieachus@attbi.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Need advice re package organization.
References: <pan.2003.07.26.13.08.25.810488@mail.utexas.edu>
 <3F228F3B.9020203@attbi.com> <yaxUa.374$XK4.16279@read1.cgocable.net>
 <3F22F9E9.3040307@attbi.com> <M2YUa.972$XK4.65085@read1.cgocable.net>
 <5jn9ivoetll1fu2avn9hmjj6aaa7q7pmjn@4ax.com>
 <y%xVa.1302$j_5.4631@news20.bellglobal.com>
 <fiveiv8h309dkvjqf6nb343osfjl41qt3o@4ax.com>
 <clWVa.4191$mv6.741217@news20.bellglobal.com>
 <vigijhb0op0t69@corp.supernews.com>
 <7DbWa.1370$qN3.183518@news20.bellglobal.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 66.31.71.243
X-Complaints-To: abuse@comcast.net
X-Trace: sccrnsc02 1059689581 66.31.71.243 (Thu, 31 Jul 2003 22:13:01 GMT)
NNTP-Posting-Date: Thu, 31 Jul 2003 22:13:01 GMT
Organization: Comcast Online
Date: Thu, 31 Jul 2003 22:13:01 GMT
Xref: archiver1.google.com comp.lang.ada:41114
Date: 2003-07-31T22:13:01+00:00
List-Id: <comp.lang.ada>

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.

-- 
"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh