Could it be that the C++ Std Library allocates memory from the Palm
OS heap in chunks? That is, even if you call malloc(1), it could be
that the library allocates 4K for it's own use, and then allocates
from that until it's full.
You've got the source code to the STL and C library, so you should be
able to track this one down. Or you could run your experiment twice
and see what happens.
-- Keith
At 3:25 PM -0400 5/24/01, Chris DiPierro wrote:
>Consider the following code:
>
> MPoint p; // MPoint is a class ... sizeof(MPoint) == 16
> UInt32 free, large;
> vector<MPoint> v;
>
> p.x = 10;
> p.y = 20;
> free = sizeof(MPoint);
> MemHeapFreeBytes (0, &free, &large);
> v.resize (100);
> MemHeapFreeBytes (0, &free, &large);
> for (UInt16 c=0; c<100; c++) {
> v[c] = p ;
> p.x ++;
> p.y ++;
> }
> MemHeapFreeBytes (0, &free, &large);
>
>sizeof(MPoint) == 16
>The first MemHeapFreeBytes reveals about 230k of free heap (Palm IIIc
>emulated).
>The second reports 225k ... which is about 5k for 100 elements of 16 bytes
>The final reports the same 225k value
>
>It works the same if I do push_back methods w/o the resize, so that's not
>helpful. Is the Palm STL implementation *that* bad that it takes nearly 4
>times the space necessary to store these elements?
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/