Re: Implementing overloaded operator new[]/delete[]
* Tristan Wibberley:
On Sun, 2007-09-23 at 23:56 +0200, Alf P. Steinbach wrote:
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.
I address this at the end, feel free to snip the rest of the email if my
final paragraphs convince you that I'm not the idiot you assumed from
the off and that you thought deserved little more than repeated
application of "? Sorry, that's meaningless to me." Because I'm
actually quite smart, and know enough C++ to know that some features
cannot be used safely in ways that seem totally obvious even when they
seem like they were intended - hence this thread. Anyway, see you at the
end of this email.
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.
Oh! So you don't have to return a built-in pointer type? How does the
caller find out the type so it can store an instance of the smart
pointer instead of built-in pointer?
You do have to return a raw pointer from the allocation function. The
purpose of obfuscation (an allocation function taking extra arguments,
technically known as a "placement" allocation function) is to force the
client code to use a macro that adds in the necessary whatever, instead
of using new[] or new directly. That macro can then e.g. rely on a
typedef in the class, or e.g. type traits, in order to select the
relevant smart pointer type to wrap the result in.
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.
eg, like an external mapping which will get slower as the number of
blocks increases, thus making new[] only sensible, in general, if there
is going to be a limited (and small) number of allocated blocks at any
time. This scenario seems an unlikely one to me, but I've been including
to show that I'm trying to thing of all possibilities in deciding
whether I should make use of new[] overloading lightly.
A C++ implementation that behaved that way would simply not be used.
3) Unspecified in general, essentially undefined behaviour
? Sorry, that's meaningless to me.
Are you an AI? I've never seen anybody avoid indicating why they didn't
understand something. The meaning seems perfectly clear - Does it turn
out to be impossible to use overloaded operator new[]/delete[] in a way
that is fast and allocates only from arbitrary locations in the middle
of the overloaded operator's own pool with only the obvious requirements
of an allocator and the validity of the pointer returned without causing
undefined behaviour?
It's possible to do fast allocations, that was the original purpose for
this language feature.
You might want to check out e.g. Loki's small object allocator for an
example.
How can it do this? Ask for so much memory in addition to that needed
for the array that it can calculate a pointer somewhere in the extra one
or more objects that has the correct alignment for its size type and
enough space for an instance? I had kind of excluded that in my head as
a wasteful thing for the implementation to do.
I suggest buying, borrowing or stealing "Modern C++ Design" by Andrei
Alexandrescu, which discusses the Loki small object allocator.
Is the fast option really that wasteful even for the most sensible
implementations? Eg If it uses a four byte integer with four byte
alignment for the count and it wants a one byte integer with one byte
alignment for the array then it has to request seven bytes instead of
five - just in case I return a pointer to a one byte integer that is at
0x??...??3
Different for operator new[] and operator new, in practice that is.
Again, see above.
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?