Re: Implementing overloaded operator new[]/delete[]
* Tristan Wibberley:
On Sun, 2007-09-23 at 23:22 +0200, Alf P. Steinbach wrote:
* Tristan Wibberley:
Doesn't "delete ptr;" normally destroy all the elements of the array
before calling the overloaded operator delete[] in my class? How will it
know how many objects to destroy - does it keep a mapping of the
pointers I've returned from my operator new[] to the number of
elements/bytes that it asked my operator new[] to allocate?
You don't have to know or care. Your code is just asked to allocate a
certain number of bytes. How the allocated chunk of memory is used is
not the allocator or deallocator function's concern.
So I don't have to make any particular alignment guarantees,
Oh, you do.
TR1 (and as I understand it, also Boost) contains some functionality
that is specifically meant to help with ensuring proper alignment.
or
guarantee that a second call will be successful even if the first
allocation is deleted?
? Sorry, that's meaningless to me. If the allocation succeeds, return
a pointer to the allocated memory, and otherwise, call the installed
new-handler or just throw std::bad_alloc.
I just have to return a pointer to memory such that a pointer to memory
within the requested number of bytes following it won't be returned by a
subsequent call at least until the next call of my operator delete[].
That's one requirement, yes.
Are those the only requirements?
Hm, so far (1) alignment, (2) being sure to never allocate from memory
that's in use, and (3) handling allocation failure properly. In
addition you should ideally (4) implement the no-throw placement forms,
both allocator and deallocator functions (the latter will be used only
if constructor throws). Not sure if there are further requirements.
If so, then I can see why allocating things with new could be slow - it
will definitely need to use some mapping of the pointers I've returned
to the number of bytes it requested.
Assuming you meant "external mapping", no, it won't. It can request the
number of bytes it needs to e.g. add an element count at the start of
the region. It's not the allocator function's concern.
In asking this I am in part looking for confirmation that usage of
overloading new[] and delete[] are either:
1) Usable only for wrapping global operator new with statistical records
or forcing failures as for unit tests,
No. Actually, apart from implementing your own per-class allocation
scheme, the main use of implementing your own allocator function that
I'm aware of is to obfuscate the new'ing of an instance of the class in
question, so that you're in practice ensured that only your own special
macro for that is used, which then guarantees that the pointer produced
is wrapped in a suitable smart pointer. In principle I guess it could
also be used to disallow dynamic allocation, although I fail to imagine
any practical use for that.
2) Slow down as the number of current allocated blocks increases and
therefore something to avoid for all but allocation from limited pools
that starts throwing bad_alloc before the number of current blocks gets
large, or
? Sorry, that's meaningless to me.
3) Unspecified in general, essentially undefined behaviour
? Sorry, that's meaningless to me.
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?