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-Thread: a07f3367d7,aa14979d20ba3045 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!feeder.erje.net!news2.arglkargh.de!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: Jacob Sparre Andersen Newsgroups: comp.lang.ada Subject: Re: Allocation question Date: 11 May 2009 14:26:48 +0200 Organization: Jacob Sparre Andersen Sender: sparre@jspa-nykredit Message-ID: <87ljp3hlkn.fsf@nbi.dk> References: <4a07fc7a$0$2855$ba620e4c@news.skynet.be> <54897f26-0d3f-421e-9426-1822a531674e@p4g2000vba.googlegroups.com> NNTP-Posting-Host: 95.209.253.190.bredband.3.dk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: munin.nbi.dk 1242044821 14025 95.209.253.190 (11 May 2009 12:27:01 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 11 May 2009 12:27:01 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 Xref: g2news2.google.com comp.lang.ada:5762 Date: 2009-05-11T14:26:48+02:00 List-Id: Ludovic Brenta wrote: > Yes. Your image is on the stack. You can increase the size of the > stack up to an operating-system-dependent maximum (see ulimit(1) on > Unix-like systems) but there is always a limit. For potentially very > large objects, I think the better approach is to allocate them on > the heap. I would suggest you hide the allocation and deallocation > inside a controlled object which you declare on the stack, e.g. Is there something which prevents an Ada compiler from allocating large, local objects on the heap rather than on the stack? Would it be very complicated to introduce a rule in a compiler (not in the language), which makes local objects larger than some limit be allocated on the stack? > For even larger objects you can make Initialize, Adjust and Finalize > much more sophisticated and store parts of the object on the heap > and part on disk. You would do that only if you think you can beat > the performance of your kernel's paging subsystem. But then you would also make careful experiments to check if your thinking was actually correct. Greetings, Jacob -- A: Yes. >Q: Are you sure? >>A: Because it reverses the logical flow of conversation. >>>Q: Why is top posting frowned upon?