how to get size of memory allocated
mithun
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
In this case, sizeof(*a).
--
Ian Collins
peter koch
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
> On 10 Nov., 06:37, mithun <mithunsi...@gmail.com> wrote:
> > 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 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
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.
--
James Kanze
peter koch
> On Nov 10, 8:14 am, peter koch <peter.koch.lar...@gmail.com> wrote:
>
>
>
>
>
> > On 10 Nov., 06:37, mithun <mithunsi...@gmail.com> wrote:
> > > 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 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.
>
> > 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.)
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
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
<newsgroup.spamfil...@virtualinfinity.net> wrote:
> peter koch wrote:
> > 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).
> 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.
--
James Kanze
Ian Collins
> peter koch wrote:
>> 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).
>
> 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).
--
Ian Collins
Jorgen Grahn
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
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
mithun
Radu
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.
peter coche wrote:
> 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.
James Kanze wrote:
> 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 wrote:
>
> 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
Well I wouldn't call using otherwise unused registers overhead! But
yes, in general there's no such thing as a free lunch.
--
Ian Collins