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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,419864ed91cc937d
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news2.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.bt.com!news.bt.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 29 Aug 2010 17:39:21 -0500
From: Brian Drummond <brian_drummond@btconnect.com>
Newsgroups: comp.lang.ada
Subject: Re: heap size exceeded for large matrices
Date: Sun, 29 Aug 2010 23:47:09 +0100
Reply-To: brian@shapes.demon.co.uk
Message-ID: <7bol761eas8q6evpsar3kbu57fnihm7q3k@4ax.com>
References: 
 <14007b1b-c290-4c73-a0ec-d3c5195b83d4@t20g2000yqa.googlegroups.com>
 <4c7a360b$0$10227$ba4acef3@reader.news.orange.fr>
 <g9tk76ljou9a3in805jes6n6pg4oqtcna6@4ax.com>
 <340c87af-1f15-4590-baa9-ec7e864b7048@l20g2000yqm.googlegroups.com>
 <4c7ada3c$0$2372$4d3efbfe@news.sover.net>
X-Newsreader: Forte Agent 1.7/32.534
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Usenet-Provider: http://www.giganews.com
X-AuthenticatedUsername: NoAuthUser
X-Trace: 
 sv3-B4SL+Zre5t8WASHPAv/E2xyGJ7aryz9I9WDAPpl4gU5mz+5D+2AXMiMljeQ2wgA9I43S5pIQ8fAsbPx!fEelbWQKsYKulXe7aO3a+HSmMyDsCFcVBJ5QXRvVRG2ioJdp8KDyB29oi1c2Y5v8em+5YC7eVQ7j!5dA=
X-Complaints-To: abuse@btinternet.com
X-DMCA-Complaints-To: abuse@btinternet.com
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint
 properly
X-Postfilter: 1.3.40
Xref: g2news1.google.com comp.lang.ada:13834
Date: 2010-08-29T23:47:09+01:00
List-Id: <comp.lang.ada>

On Sun, 29 Aug 2010 18:06:46 -0400, "Peter C. Chapin" <chapinp@acm.org> wrote:

>On 2010-08-29 12:16, John Raymond Dore wrote:
>
>>> I replaced
>>>
>>> my_array: my_array_type (1..10000,  1..10000);
>>>
>>> with
>>>
>>> my_array_ptr : access my_array_type := new my_array_type (1..10000,  1..10000);
>>> my_array : my_array_type renames my_array_ptr.all;
>>>
>>> The rename meant I didn't have to rewrite anything else in the application.
>>>
>>> - Brian
>> 
>> Brilliant elegant solution to my problem Brian.
>> It works just fine.
>
>Be aware that you may now have to explicitly deallocate the array at
>some point. How necessary that is will depend on your program and some
>other factors. It's something to keep in mind.

Certainly worth pointing out, depending on the application (and possibly the
compiler?)

In my usage the "new" allocation is usually in the declare... section of a local
block, with no tricks on the access type, so the intended lifetime is the block
itself. 

It seems that the deallocation in this case could be automated - and in crude
tests enclosing the block in a loop I couldn't see memory use increasing with
time ... perhaps this is not the case, I wasn't looking carefully enough?

- Brian