how to get size of memory allocated

[mithun]

Hi,
In the following code snippet ....

#include<stdio.h>
#include<iostream>
using namespace std;

class A
{
int a,b;
char c,d;
};
main()
{
A *a = new A();
cout<<"\n"<<sizeof(a);
}

The following code gives output 4 as 'a' is pointer. I want to get the
complete size of object allocated ie 10. How can this be done.

-Mithun

 

[Ian Collins]

Hi,
In the following code snippet ....

#include<stdio.h>
#include<iostream>
using namespace std;

class A
{
int a,b;
char c,d;
};
main()
{
A *a = new A();
cout<<"\n"<<sizeof(a);
}

The following code gives output 4 as 'a' is pointer. I want to get the
complete size of object allocated ie 10. How can this be done.

In this case, sizeof(*a).

 

[peter koch]

Hi,
   In the following code snippet ....

                #include<stdio.h>
                #include<iostream>
                using namespace std;

              class A
              {
                       int a,b;
                      char c,d;
              };
             main()
             {
                   A *a =  new A();
                cout<<"\n"<<sizeof(a);
              }

The following code gives output 4 as 'a' is pointer. I want to get the
complete size of object allocated ie 10. How can this be done.

I would guess sizeof A to be 12, not 10. It is trivial to get the size
of an A, but that does not give the size of the memory allocated. At
least sizeof A bytes will be allocated, but it could easily be more -
12, 16, 24 and 32 would be probable numbers.

/Peter

 

[James Kanze]

I would guess sizeof A to be 12, not 10.

It depends on the machine. I'm aware of processors where it
will be 18, and I've heard of some where it will be 4. (But on
common desktop machines, yes, it will be 12.)

It is trivial to get the size of an A, but that does not give
the size of the memory allocated. At least sizeof A bytes will
be allocated, but it could easily be more - 12, 16, 24 and 32
would be probable numbers.

Off hand, I don't know of any system where the amount of memory
allocated will not be at least a pointer more than what is
requested. Typically, alignment considerations, the algorithm
and such may make it even more. Sometimes much more. (IIRC,
the malloc bundled with the Berkley kernel would add 8, then
round up to the next power of 2.)

 

[James Kanze]

mithun wrote:

In this case, sizeof(*a).

But not necessarily in the general case. sizeof only takes the
static type into consideration, not the dynamic type.

 

[peter koch]

It depends on the machine.  I'm aware of processors where it
will be 18, and I've heard of some where it will be 4.  (But on
common desktop machines, yes, it will be 12.)

Yes. My guess was based on the information from the post, strongly
indicating a size of 12.

Off hand, I don't know of any system where the amount of memory
allocated will not be at least a pointer more than what is
requested.  Typically, alignment considerations, the algorithm
and such may make it even more.  Sometimes much more.  (IIRC,
the malloc bundled with the Berkley kernel would add 8, then
round up to the next power of 2.)

Some allocators are optimised to provide no overhead for small
allocations - and I guess a size of 12 would be small. In such a case,
it would be possible to have a zero size overhead. I don't know if any
implementation of new uses such a strategy by default, but if not, you
could write your own (or grab the one implemented by Alexandrescu).

/Peter

 

[Daniel Pitts]

Some allocators are optimised to provide no overhead for small
allocations - and I guess a size of 12 would be small. In such a case,
it would be possible to have a zero size overhead. I don't know if any
implementation of new uses such a strategy by default, but if not, you
could write your own (or grab the one implemented by Alexandrescu).

/Peter

I don't see how that's possible. I don't see how you could have zero
overhead and still be able to deallocate the memory properly.

 

[peter koch]

I don't see how that's possible. I don't see how you could have zero
overhead and still be able to deallocate the memory properly.

The principle is to have a segment of equal-sized memory blocks. If
the pointer you release points to that segment, you know the size of
the allocation.

/Peter

 

[James Kanze]

I don't see how that's possible. I don't see how you could
have zero overhead and still be able to deallocate the memory
properly.

It's not too difficult, but it generally means that once memory
has been allocated with one size, it can't be coalised with
neighbors to serve a larger size, nor divided for a smaller
size. Most fixed length allocators have practically no
overhead, so you just use a fixed length allocator for each of
the smaller sizes you see. (There's still some overhead, of
course, in order to maintain alignment.) The only remaining
problem is in delete, to determine whether the memory is in from
one of the fixed length allocators or not; this can typically be
done based on its address, but with some additional runtime
overhead.

 

[Ian Collins]

I don't see how that's possible. I don't see how you could have zero
overhead and still be able to deallocate the memory properly.

One of my better allocators was written on a 386 where I used a local
descriptor table entry per allocation (which imposed a limit of 4096
blocks).

 

[Jorgen Grahn]

I would guess sizeof A to be 12, not 10. It is trivial to get the size
of an A, but that does not give the size of the memory allocated. At
least sizeof A bytes will be allocated, but it could easily be more -
12, 16, 24 and 32 would be probable numbers.

It is also possible that "mithun" wanted something even more general:

memoryuseof(*a);
memoryuseof(std::string("foo"));
memoryuseof(std::vector(42, *a));

finding out how much "heap space" an object uses, including memory
pointed to.

(Such a thing doesn't exist, I think. Certainly not in the language.)

/Jorgen

 

[mithun]

Thanks for the Reply...yeah this was my Question...

 

[Radu]

Thanks for the Reply...yeah this was my Question...

I found a function in MSDN called _msize that is suposed to return the
size of a block allocated in the heap: http://msdn.microsoft.com/en-us/library/z2s077bc(VS.80).aspx
(example here: http://msdn.microsoft.com/en-us/library/xbebcx7d(VS.80).aspx
)
It only works for pointers but as far as I have seen it reports
correctly the size of block.

Hope it helps.

 

[Daniel Pitts]

I don't see how that's possible. I don't see how you could have zero
overhead and still be able to deallocate the memory properly.

The principle is to have a segment of equal-sized memory blocks. If
the pointer you release points to that segment, you know the size of
the allocation.

It's not too difficult, but it generally means that once memory
has been allocated with one size, it can't be coalised with
neighbors to serve a larger size, nor divided for a smaller
size. Most fixed length allocators have practically no
overhead, so you just use a fixed length allocator for each of
the smaller sizes you see. (There's still some overhead, of
course, in order to maintain alignment.) The only remaining
problem is in delete, to determine whether the memory is in from
one of the fixed length allocators or not; this can typically be
done based on its address, but with some additional runtime
overhead.

One of my better allocators was written on a 386 where I used a local
descriptor table entry per allocation (which imposed a limit of 4096
blocks).

Thanks for the replies Peter, James, and Ian,

It seems like all those methods have overhead or waste in one form or
another. The overhead was just moved from place to place. Although
they may improve performance or reduce overall space+time overhead, they
are still not zero

 

[Ian Collins]

Thanks for the replies Peter, James, and Ian,

It seems like all those methods have overhead or waste in one form or
another. The overhead was just moved from place to place. Although
they may improve performance or reduce overall space+time overhead, they
are still not zero

Well I wouldn't call using otherwise unused registers overhead! But
yes, in general there's no such thing as a free lunch.