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

[veenurs <ve...@ma...>]

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 expect
>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 previously
>released memory block.
>
>The buddy system or a binary subdivision are the extremes, where you might
>get +50 - 100% extra memory even for large allocations. The advantages are
>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ázs wrote:
>
>  
>
>>Hello!
>>
>>veenurs wrote:
>>    
>>
>>>if( (buffer = ( PBYTE )calloc( 1000 ,sizeof(BYTE) )) == NULL ){
>>>}
>>>size = _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 money
>>for example, I would rather keep it, than complaining about it :)
>>--
>>Greetings,
>>   Balázs
>>
>>
>>
>>-------------------------------------------------------
>>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
>
>  
>