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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,86f12c6cc81fafe X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!news-lei1.dfn.de!news1.uni-leipzig.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Alex R. Mosteo" Newsgroups: comp.lang.ada Subject: Re: exception access violation Date: Wed, 15 Nov 2006 14:32:11 +0100 Message-ID: <4s0j3hFtng3pU1@mid.individual.net> References: <1163446297.630444.280740@b28g2000cwb.googlegroups.com> <4rtfa8FsioqkU1@mid.individual.net> <1163532883.352177.211940@m73g2000cwd.googlegroups.com> <4s06i8FsekphU1@mid.individual.net> <1163584330.6500.6.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: individual.net V0TgSMYeXOGKHz1/+gYHGwe6jSSF8o9+nsugH3WMuci9uyf9g= User-Agent: KNode/0.10.4 Xref: g2news2.google.com comp.lang.ada:7473 Date: 2006-11-15T14:32:11+01:00 List-Id: Georg Bauhaus wrote: > Why is using the heap + controlled for larger data structures > more portable than using the stack? I know that GNAT needs to > be talked into providing sufficient space on the stack. > You might be that running into this kind of stack trouble only > when you port from another compiler to GNAT? I have no experiences out of GNAT, that be said first. In past times, I had to deal with implicit limits in Linux/ld (I seem to remember it was 2MB. This has changed with kernels and is no longer an issue). Because of this, porting from Windows to Linux was somewhat painful because problems not arising in Windows did arise in Linux (even using the usual linker stack options, so I had to dig for even more obscure switches). Other languages don't exploit so much the stack, so it is more difficult to find experiences in the area from other developers. Other point that may be relevant: by default, gnat doesn't release memory historically claimed by stacks, contrarily to heap-allocated one. Couple this with lots of tasks or recursivity and quickly memory can start to be an issue. (I'm not sure if this is linux 2.6 default behavior or gnat management of secondary stacks, couldn't locate it in the docs). Finally is the trap I always fall for: "This is small enough to be in the stack". And then it grows, and then it starts to be a problem, or some recursive algorithm can't recurse enough, and you end changing it or having humongous stacks or reworking algorithms. Of course, in realtime environments you'll prefer to know your memory needs from the start. > Should the decision whether some object lives on the heap or on > the stack be based on compilers' support for dynamically sized > local data structures? As long as compilers are not perfect, I suppose it is at least an extra factor to consider. Also, I'd not limit it only to dynamically sized data. I've been bitten several times by stack-related problems when using GNAT, that's all I wanted to transmit (hence the 'in my experience' remark). If you don't have desires to learn about system internals, GNAT primary/secondary stacks and so... use the heap, luke ;) It is worrysome that I'm saying all this, because I find much more comfortable using the stack than any heap management.