Garbage Collection

[helios]

If you forget to delete a RAII object, the resource won't be automatically released.

...Huh? Are you using "RAII" in some novel sense I'm not aware of?

[moorecm]

Better not throw!

[chrisname]

If you forget to delete a RAII object, the resource won't be automatically released.

...Huh? Are you using "RAII" in some novel sense I'm not aware of?

This, that's the whole point of RAII.

[LB]

I have always been confused...if things like the delete[] operator know how much memory they allocated given the address to it, I have a hard time understanding why at the end of a program the memory is not automatically freed?

[Albatross]

I never really looked into the details (and I really should) but I'm guessing that the standard C++ allocator has some way of checking the ownership of a certain byte of memory, and that what delete [] does is just iterates forward byte-by-byte and frees memory until it encounters a byte that wasn't reserved to the program.

-Albatross

[Catfish]

@ Albatross: I read somewhere^* that new[] (and delete[]) simply also stores (takes into account) the number of elements bytes they allocate memory for that were allocated.

It would be nice if your idea was implemented by some compilers, though... well actually if your idea of ownership metadata was put in practice, we'd have a full GC.

^* http://yosefk.com/c++fqa/heap.html#fqa-16.12

Edit: what am I writing!

[helios]

if things like the delete[] operator know how much memory they allocated given the address to it, I have a hard time understanding why at the end of a program the memory is not automatically freed?

Because the size of the buffer is usually stored in (size_t *)((unsigned size_t)p-sizeof(size_t)), where p is the pointer returned by new[]. To be able to free buffers, it would be necessary to also keep a list of pointers returned to the application.
Unless the OS doesn't do paging, freeing a buffer at the very end doesn't make a lot of sense, anyway. Destructors can't be called because the order of execution can't be guaranteed, even though the program may depend on that.

I'm guessing that the standard C++ allocator has some way of checking the ownership of a certain byte of memory, and that what delete [] does is just iterates forward byte-by-byte and frees memory until it encounters a byte that wasn't reserved to the program.

Nope. A bitmap would be way too inefficient for allocation and deallocation. The most common implementation of malloc() is a list of unallocated chunks of virtual memory. When an allocation occurs, the chunk that supplied the buffer is resized accordingly (it involves just setting an integer), and perhaps deleted; when a deallocation occurs, chunks may be merged or created.

[Albatross]

Bitmaps are inefficient, yes, though it wouldn't surprise me terribly if they were used. However, regardless, thanks for sharing!

-Albatross

[LB]

Ah, ok. Storing the size just before the data makes a lot more sense! I was under the impression that new[] added the returned pointer and data size to some table, and that delete[] looked it up. Thanks for the info helios! :)