7

Possible Duplicate:
C programming : How does free know how much to free?

How does delete know how many bytes it has to free? I read that there is some block before the actual pointer address that is returned by new which contains block address details.

Anyone here who knows how many bytes this block has or how the format of that block is?

Community
  • 1
  • 1
Vijay
  • 2,021
  • 4
  • 24
  • 33

3 Answers3

7

In general, this is implementation-dependent.

The way this is usually implemented is that new/malloc will allocate slightly more bytes than you asked for, and will use the extra bytes for some book-keeping: many times the allocated blocks will also be maintained in a linked-list, and so the extra bytes will be used to store the next/prev pointer, as well as the size of the block.

This is not mandatory, however. The new/malloc calls can just as well store your pointer and the block's size in, say, a map.

If you're interested in a specific implementation, you will have to provide more information (e.g. what runtime/compiler are you using?).

telewin
  • 1,102
  • 8
  • 17
1

new operator and malloc function handle memory in their own particular ways, so

  • if you allocated memory with 'new' uses 'delete'
  • if you allocated memory with 'malloc' uses 'free'
  • if you don't know how/who/where the memory have been allocated, don't free it

If you are bound to try to mess up with the inner workings of malloc or new (which seems to be your goal), you're doing it wrong ^^

Monkey
  • 1,838
  • 1
  • 17
  • 24
1

There's no single right answer to that question because it depends on the situation. In some cases the compiler knows the size of the object at compile time and thus delete knows how many bytes to free. In situations where the memory size not known at compile time there either a memory map involved or as you yourself suggested, a word preceding the pointer, that tells number of allocated bytes.

I believe a lot of this is implementation specific not something you can rely on to go about a specific way. This question is very similar to this one.

Community
  • 1
  • 1
John Leidegren
  • 59,920
  • 20
  • 131
  • 152
  • Are you sure about the "In some cases the compiler knows the size of the object at compile time and thus delete knows how many bytes to free" part? I don't think that this is possible, and even it if is that would require the system two be able to allocate thing on the heap in two different ways. – Lindydancer Mar 24 '11 at 07:17
  • @Lindydancer - Well, yes of course! And there's nothing wrong with that. The sizeof keyword for instance, is used to determine the size of an object at compile time. And that the compiler generates different code depending on the type of allocation or deallocation is not particularly farfetched. All this is implementation specific. – John Leidegren Mar 24 '11 at 08:18
  • @John - The reason I asked is because I've been writing C/C++ compilers for more than 10 years, and I've never seen this. As a special `delete` operator would be required that take the size (as opposed to picking it up via the pointer), the compiler must be able to find all calls to `new` and corresponding calls to `delete`. This pointer must not escape and be deleted by a normal `delete` and this special delete must not delete a normal pointer. Do you have a concrete example of a compiler that does this? – Lindydancer Mar 24 '11 at 09:33
  • @Lindydancer - My C/C++ is not perfect but as long as you don't allocate *objects* using malloc something like that would work. But then C/C++ doesn't really have types in the sense that a pointer has a specific type or is locked to having a specific type. I know that you can do some type testing with RTTI but I don't know if this is ever involved in the actual memory management of such objects. – John Leidegren Mar 24 '11 at 12:24
  • @Lindydancer - Either way, RTTI is the opposite of compile time and I suppose you're right. The memory management in C++ is explicit and I've been spoiled by managed code for too long. – John Leidegren Mar 24 '11 at 16:51
  • Thanks for an interesting discussion non the less. It´s always interesting to find new ways to handle things, even if this probably won't be feasible. – Lindydancer Mar 24 '11 at 16:57