From: Eryndlia Mavourneen <eryndlia@gmail.com>
Subject: Re: Bug in GNAT? - Max_size_in_storage_elements insufficient
Date: Wed, 19 Oct 2016 08:45:44 -0700 (PDT)
Date: 2016-10-19T08:45:44-07:00 [thread overview]
Message-ID: <9b150fbf-46fc-4861-8bf2-65df9d04f41f@googlegroups.com> (raw)
In-Reply-To: <nu5ev1$lgp$1@gioia.aioe.org>
On Tuesday, October 18, 2016 at 10:26:28 AM UTC-5, Vratislav Podzimek wrote:
> Well, then it's at least a bug in [Barnes] because there's an example
> like the above ones just with a simpler type. But I still think the idea
> here is/was to provide enough space for N items of some type. That's what
> the 'Max_size_in_storage_elements' attribute should be good for. And
> there's no fragmentation nor history of allocation/deallocation in my
> case. If I specify I want space for 4 records, I should get space for 4
> records. Not slightly less due to some hidden, unpredictable overhead.
There is another use for the attribute Max_Size_In_Storage_Elements. That is to allow a dynamic allocation on the stack for an object whose size and subtype you may not know until run-time. This can occur when receiving messages over a communications link or when reading from a loosely-defined file. This type of thing, otherwise, is not good design and is questionable even in this case.
-- Eryndlia
next prev parent reply other threads:[~2016-10-19 15:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-18 11:17 Bug in GNAT? - Max_size_in_storage_elements insufficient Vratislav Podzimek
2016-10-18 12:35 ` Dmitry A. Kazakov
2016-10-18 15:26 ` Vratislav Podzimek
2016-10-18 16:03 ` Dmitry A. Kazakov
2016-10-19 1:39 ` Luke A. Guest
2016-10-19 7:33 ` Dmitry A. Kazakov
2016-10-20 0:59 ` Randy Brukardt
2016-10-19 15:45 ` Eryndlia Mavourneen [this message]
2016-10-19 15:53 ` Eryndlia Mavourneen
2016-10-19 13:34 ` Egil H H
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox