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: stt@henning.camb.inmet.com (Tucker Taft) Subject: Re: Q: memory management Date: 1996/06/17 Message-ID: #1/1 X-Deja-AN: 160545194 sender: news@inmet.camb.inmet.com (USENET news) x-nntp-posting-host: henning.camb.inmet.com references: organization: Intermetrics, Inc. newsgroups: comp.lang.ada Date: 1996-06-17T00:00:00+00:00 List-Id: Hannes Haug (Hannes.Haug@Student.Uni-Tuebingen.de) wrote: : 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. Does the size vary from one allocation to the next, or are they all the same size? If they are all the same size, you may declare the access type with a constrained designated subtype, such as: subtype Alloc_Buffer is String(1..Num_Chars); type Space_Ptr is access all Alloc_Buffer; ... X : Space_Ptr := new Alloc_Buffer; ... Pass_To_Assembler(X.all'Address); In most compilers, no bounds would be stored in the heap for such an allocation, since the bounds do not vary from allocation to allocation. : >> Does "Allocate (some_storage_pool, addr, n, Word_Size / : >> Storage_Unit)" work ? Which storage pool do I have to choose ? This should work. The storage pool would be specified via Some_Access_Type'Storage_Pool where Some_Access_Type is any access type declared at the library level. It would be safest if the access type had an unconstrained designated subtype, such as: type Some_Access_Type is access all String; to avoid the implementation-chosen storage pool from being one that only works on access collections of uniformly-sized objects. : Not possible. Perhaps I have to use malloc. If you are interfacing with C, then using "malloc" via a pragma Import makes sense. If you are interfacing with assembler, it seems silly to drag in the C run-time support, unless you know it will already be there for other reasons. : - hannes -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Cambridge, MA USA