RE: Trying to get the size of a Datastructure through the pointer? Possible? Not having good luck with it...

Hi Jon

Is that a hunch or is that based on some previous dealings in that area?

This kind of stuff really interests me (but I don't know a lot about it)!

My initial thought was wow in a language like c++ on the 400 (pseudo) code
like this code be a killer;

For int i = 0;i< 100 i++) {
Some64ByteObject obj = new Some64ByteObject();

}

Instead of allocating 6400 bytes it could allocate 9200 bytes, that feels
like a lot of wasted ram?

I do know that most malloc implementations write a 16 byte header that
describes the allocated memory, then calls to dealloc (and realoc) knock 16
bytes off the pointer passed in to get to the header which stores the total
number of bytes stored.

Could this be the extra overhead you are referring to?

Neill



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Jon Paris
Sent: 19 November 2010 17:51
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Trying to get the size of a Datastructure through the pointer?
Possible? Not having good luck with it...

I've never seen such an instruction but I don't think it would help
anyway. I believe that to avoid checker-boarding of memory, the system
will often return an allocation larger than you asked for. For example
if you ask for 64 bytes and it has a block of 96 bytes available it
will give you that 96 rather than leave a (probably) unusable 32 byte
"hole".


Jon Paris

www.Partner400.com
www.SystemiDeveloper.com



On Nov 19, 2010, at 12:35 PM, rpg400-l-request@xxxxxxxxxxxx wrote:

It *may* be possible to determine how much memory the system
allocated for a
basing pointer using an MI instruction, but that allocated memory
would
always be in increments of 16 bytes (at a minimum), so even if you
could get
that value, all you'd really be able to figure out is that your
data-structure is no larger than that size.