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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,42a57c8ee023f14d X-Google-Attributes: gid103376,public From: jsa@organon.com (Jon S Anthony) Subject: Re: Q: memory management Date: 1996/06/18 Message-ID: #1/1 X-Deja-AN: 160866100 sender: news@organon.com (news) references: organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-06-18T00:00:00+00:00 List-Id: In article Hannes Haug writes: > > Jon> the reserved word _new_ in an allocator context. [...] > > I know about new. > > > >> I think "new Storage_Array (n)" will give me a little bit too > >> much storage. The array bounds need some space. > > Jon> I don't know what "storage_array" is, but don't worry about > Jon> the space for bounds. It's all taken care of for you. > > But I really just want a pointer to some amount of storage. I have to > pass it to som assembly routines. This routines cannot benefit from the > bounds in the array representatio. They would even overwrite them. And > I have to worry about space. The here useless bounds would cost me at > least 1MB. I see that I have misunderstood again. :-( That's two strikes. I wonder if I've blown the last one... If you use constrained arrays, you should there should not be any array bounds involved in the memory allocation. If you need to have variable amounts you can try this: Somewhere after you've figured out what n is: ... declare subtype The_Storage_Type is Storage_Array(n); type Storage_Ref is access The_Storage_Type; The_Storage : Storage_Ref := new The_Storage_Type; begin ... Stuff... end; There's no reason in this context for allocating the bounds with the actual storage for The_Storage. Then again, I don't think there is any guarantee either (I would be surprised if they were included, but...) If this isn't good enough then you really will need to resort to defining your own storage pools. That would allow you to redefine what happens when _new_ is used as an allocator for an access type associated with the pool. > Jon> At this point don't worry about user defined storage pools > Jon> and allocation/deallocation. Just use the standard > Jon> predefined ones. > > Not possible. Perhaps I have to use malloc. Well, this is just me bungling the answer. In your case you may well want to use your own storage pools. Note that if you do, you could use malloc as part of the implementation of them if you discovered that there was a good reason for this. Actually, in the case of GNAT I think predefined _new_ turns into malloc anyway... /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com