   c++ hard question
  Hello,Yesterday i stumbled upon the following question:"How does `free` know how many bytes to free?"Apparently c++ has a system of storing the size when you call `malloc` or `new`.And there is not much information on google about this, all i found was crap , now working code and people saying "you can't get that value , it's impossible , you have to store it yourself, bla bla bla"How can that value be accessed?? , it has to be somewhere.Thanks, Raxvan.   
Quote:Original post by MakaanHello,Yesterday i stumbled upon the following question:"How does `free` know how many bytes to free?"Apparently c++ has a system of storing the size when you call `malloc` or `new`.And there is not much information on google about this, all i found was crap , now working code and people saying "you can't get that value , it's impossible , you have to store it yourself, bla bla bla"How can that value be accessed?? , it has to be somewhere.Thanks, Raxvan.Heh, I ask the same thing. Maybe it stores a list somewhere with pointer and size together...but we should be able to access it in SOME way, shouldn't we?   ;The C++ FAQ Lite has a nice answer to this (section 16.14).  As far as accessing that value goes, I don't think there is a way to do it (though I can't verify that).  Sure, you could hack it and write some code that could, but that wouldn't be a very good idea.   ;Quote:Original post by MikeTacularThe C++ FAQ Lite has a nice answer to this (section 16.14).  As far as accessing that value goes, I don't think there is a way to do it (though I can't verify that).  Sure, you could hack it and write some code that could, but that wouldn't be a very good idea.There's no standard way to get this value, no. Some implementations allocate 4 bytes before the main allocation and store the allocation size there, some might have some sort of linked list of allocations, some might keep the length in some other data structure, it's impossible to tell.   ;  If you want a good read about the internals and tradeoffs that an allocator has to make then dlmalloc has a good explanation of it's inner workings.Quote:How can that value be accessed?? , it has to be somewhere.Not necessarily. One common technique for small allocations is to have a series of pools holding fixed size chunks of memory (eg. 16 bytes long, 32 bytes long, 64 bytes long, etc. etc.). When you allocate it'll just pick the smallest available chunk which is big enough. When it comes to free it the system doesn't care how big it actually is, but because it knows from the pointer value that it belongs to a particular pool and so the chunk is (say) 256 bytes in size. The knowledge that you only allocated 200 bytes is lost.   ;Quote:Original post by Evil SteveQuote:Original post by MikeTacularThe C++ FAQ Lite has a nice answer to this (section 16.14).  As far as accessing that value goes, I don't think there is a way to do it (though I can't verify that).  Sure, you could hack it and write some code that could, but that wouldn't be a very good idea.There's no standard way to get this value, no. Some implementations allocate 4 bytes before the main allocation and store the allocation size there, some might have some sort of linked list of allocations, some might keep the length in some other data structure, it's impossible to tell.Cool, good to know for sure.  I didn't think there was a way to do it (at least not a safe, portable, and legal way), but I'm not a standards guru.  Thanks for the reinforcement!   ;  Thanks for the answers , this makes more sense now.Still this raises the question why there is no default builtin "lengthof" system,it would make life easier :) .   ;Quote:Original post by MakaanThanks for the answers , this makes more sense now.Still this raises the question why there is no default builtin "lengthof" system,it would make life easier :) .Because if you need to know the length of a chunk of memory you allocated, you can easily keep the length around (Or use std::vector or other container that manages it for you). Forcing every implementation to have a way to access the size of the allocated memory could prevent certain optimisations (Such as the one OrangyTang described).   ;Quote:Original post by Evil SteveForcing every implementation to have a way to access the size of the allocated memory could prevent certain optimisations (Such as the one OrangyTang described).Forcing every implementation??? no, free and delete already have this implementation, and it might prevent optimisations, but hey if don't want it don't use it.;Quote:Original post by MakaanQuote:Original post by Evil SteveForcing every implementation to have a way to access the size of the allocated memory could prevent certain optimisations (Such as the one OrangyTang described).Forcing every implementation??? no, free and delete already have this implementation, and it might prevent optimisations, but hey if don't want it don't use it.Every single malloc / new implementation would have to store the length of the allocation somewhere for lengthof() to work. It might not be that big a deal, but likewise it's not that big a deal to keep track of the size yourself - you should always know how big an allocation is.Some implementations don't know how much memory is allocated by a call to malloc - as OrangyTang said; there might just be multiple fixed sized buckets.   