Georg C. F. Greve wrote in message ...
>It is common knowledge that every allocation carries a certain bit of
>overhead - meaning the memory "above" the actual memory that carries
>internal system information.
>
>As far as I know this is usually a system-dependant, constant amount
>(if that should be wrong, please tell me)

This is common, but there are plenty of exceptions.  For small objects that
don't need to be padded there are strategies that have an amortized overhead
of only a few percent of the object's size.  Many systems will pad a user
requested size to some larger number (say a generalized alignment number or
a power of two) before or after adding overhead for each object.  Some
debugging allocators will save the current call stack associated with each
allocated block.  This implies that the overhead is proportional to the call
depth.

> - is there any clean,
>"standardized" way of retrieving the size of this overhead?

The short answer is no.  Talk to your vendor or to a system-specific news
group to get answers, or use a debugger that really lets you see what is
going on.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

--pgp-sign-Multipart_Sat_Oct_30_17:11:46_1999-1
Content-Type: text/plain; charset=US-ASCII

Hi Everybody!

It is common knowledge that every allocation carries a certain bit of
overhead - meaning the memory "above" the actual memory that carries
internal system information.

As far as I know this is usually a system-dependant, constant amount
(if that should be wrong, please tell me) - is there any clean,
"standardized" way of retrieving the size of this overhead?

Regards,
  Georg

--
Georg C. F. Greve <greve@gnu.org>
``Real programmers confuse Christmas and Halloween
  because DEC 25 = OCT 31.''            -- Unknown

--pgp-sign-Multipart_Sat_Oct_30_17:11:46_1999-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP MESSAGE-----
Version: 2.6.3i
Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface

iQCVAwUBOBsKuFZXgZXDxqJtAQGLxAQAiFlQYwRe8gvYu97yDeP0WtOdEWBLYtSt
70y1Q/gcYGhLnxwk+KH28LRh0K474ELfZ2yAWBgho2u3XuUYN/fEt8RAVPsvsfRl
fPQLRi+n9E/ZlYvN2GxrWOVS3ppEx6qKa0ts6W8lLHPcv0nTPOV2EasO3fW1Zvtu
YPprMJVTVJA=
=m935
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Sat_Oct_30_17:11:46_1999-1--
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 31 Oct 99 04:57:41 GMT, "Georg C. F. Greve" <greve@gnu.org> wrote:

>It is common knowledge that every allocation carries a certain bit of
>overhead - meaning the memory "above" the actual memory that carries
>internal system information.
>
>As far as I know this is usually a system-dependant, constant amount
>(if that should be wrong, please tell me) - is there any clean,
>"standardized" way of retrieving the size of this overhead?

No, there is no portable way to find the overhead, or where it is, or
if there is any. Nor is it necessarily the case that overhead is
constant for an implementation.

In typical implementations, a fixed amount of extra space is allocated
ahead of the pointer returned by malloc or new, but that is just one
possible method.

A system using a "buddy allocator" does not need to store the
allocation size. There is overhead in the form of wasted space, but it
shows up as more space having been allocated than you asked for. (The
number of bytes allocated is always a power of 2.)

An allocator might use lists of fixed-size blocks. There isn't
necessarily overhead associated with any particular allocation, but
there is system overhead in the associated data structures.

With any allocation scheme, a request for some size might result in
getting more than you asked for -- rounded up to a multiple of some
small integer, for example.

Portable code cannot make ANY assumptions about the space returned by
an allocator, except that you get as much space as you asked for,
aligned strictly enough for the size of the request.

---
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]