Re: [Dev-C++] Re: malloc , extra bytes ! Not so urgent now .

[Per W. <pw...@ia...>]

The Win32 API have a long tradition of adding a cbSize (something) entry
to a lot of structures passed to or from the OS. The reason for this is
that the OS might later extend the size of the structures, and by looking
at the size member received from the application, it can differentiate
between an old or new application, i.e. if the application was compiled
with old or new header files.

This allows easy addition of new member values in the structures without
extending or adding new Win32 API functions. It isn't a way around any
malloc() problems, but a way to perform run-time type checking, or
actually a way to perform function overloading depending on what type of
buffer pointer was sent in. An example is GetMonitorInfo() which takes a
MONITORINFO* parameter, or GetOutlineTextMetrics which takes a
OUTLINETEXTMETRIC*, GetOutputFormats with DDPIXELFORMAT*...

One side effect of this is that a lot of GetXX() calls normally fails if
you just do a ZeroMemory() on the structure before the request, and
forgets to set xx.cbSize =3D sizeof(xx).

/Per W

On Tue, 25 Feb 2003, veenurs wrote:

> Enlightening , man !
>
> I don't know much abt . compilers , so tell me -
> When is the decision to allocate ( how much of ) the memory made - at
> compilation or runtime .  If  at runtime , then why did I always got
>  "snug fit" with other compilers ?
> The windows API tutorials are replete  with things like dwFileSize etc,
> which do give you sizes without much fuss ( That data comes from some
> behind the scene  struct members, I guess ) .That's how I was fooled
> into relying on such  tactics with  my own pointers :-0 .Nice timely
> jolt , though  .
> -Rahul .
>
> Per Westermark wrote:
>
> >The main reasons for allicating larger memory blocks than requested are:
> >- Make sure the hidden header before any allocated data are always
> >aligned. Aligned data is faster to access. Also, most processors
> >doesn't support unaligned memory. The x86 series processors are just
> >very-very nice.
> >- Make sure that the returned pointer get a very high alignment -
> >normally at least align 8, to allow perfectly aligned 64-bit integers
> >and doubles. Remember that the runtime library doesn't know if you expec=
t
> >to store 1024 single bytes or 128 doubles in a 1kB request.
> >- Reduce memory fragmentation. By limiting number of allowed block sizes=
,
> >new requests have a higher probability of being able to reuse a previous=
ly
> >released memory block.
> >
> >The buddy system or a binary subdivision are the extremes, where you mig=
ht
> >get +50 - 100% extra memory even for large allocations. The advantages a=
re
> >that they are lightning-fast at locating available blocks or subdividing=
 a
> >too large block into a returnable chunk. When you return a block of
> >memory, they know exactly where the neighbours are, and can check if the
> >neighbour has also been released thereby directly combining multiple
> >released blocks into the next larger block size.
> >
> >/Per W
> >
> >On Mon, 24 Feb 2003, OROSZI Bal=E1zs wrote:
> >
> >
> >
> >>Hello!
> >>
> >>veenurs wrote:
> >>
> >>
> >>>if( (buffer =3D ( PBYTE )calloc( 1000 ,sizeof(BYTE) )) =3D=3D NULL ){
> >>>}
> >>>size =3D _msize( buffer );
> >>>The size I get it is not 1000 , but 1008  !Same for malloc.
> >>>
> >>>
> >> From the C Runtime Library Reference:
> >>
> >>----
> >>Syntax
> >>
> >>#include <malloc.h>
> >>size_t _msize(void *block);
> >>
> >>Description
> >>
> >>Returns the size of a heap block.
> >>
> >>_msize returns the size of the allocated heap block whose address is
> >>block. The block must have been allocated with malloc, calloc, or
> >>realloc. The returned size can be larger than the number of bytes
> >>originally requested when the block was allocated.
> >>
> >>Return Value
> >>
> >>_msize returns the size of the block in bytes.
> >>----
> >>
> >>Especially take care of this sentence:
> >>The returned size can be larger than the number of bytes originally
> >>requested when the block was allocated.
> >>
> >>I suppose the reason for this is because it would take longer to give
> >>you the EXACT amount of memory, so it gives the amount that is nearly
> >>(and at least) what you need, but what can be given the fastest - only
> >>what I think.
> >>
> >>But you should always use the REQUESTED amount, not the actually
> >>RECIEVED amount. If calloc doesn't return NULL, then the requested
> >>amount is at your hand for sure.
> >>
> >>Anyway, why is it a problem if you have more memory? If I get more mone=
y
> >>for example, I would rather keep it, than complaining about it :)
> >>--
> >>Greetings,
> >>   Bal=E1zs
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This sf.net email is sponsored by:ThinkGeek
> >>Welcome to geek heaven.
> >>http://thinkgeek.com/sf
> >>_______________________________________________
> >>Dev-cpp-users mailing list
> >>Dev...@li...
> >>TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> >>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> >>
> >>
> >>
> >
> >
> >
> >-------------------------------------------------------
> >This sf.net email is sponsored by:ThinkGeek
> >Welcome to geek heaven.
> >http://thinkgeek.com/sf
> >_______________________________________________
> >Dev-cpp-users mailing list
> >Dev...@li...
> >TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> >https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> >
> >
> >
>
>