I currently allocate my memory for arrays using the MS specific mm_malloc. I align the memory, as I'm doing some heavy duty math and the vectorization takes advantage of the alignment. I was wondering if anyone knows how to overload the new operator to do the same thing, as I feel dirty malloc'ing everywhere (and would eventually like to also compile on Linux)? Thanks for any help
Asked
Active
Viewed 1.1k times
2 Answers
10
First of all, it's important to note that new
and delete
can be overloaded either globally, or just for a single class. Both cases are shown in this article. Also important to note is that if you overload new
you almost certainly also want to overload delete
.
There are a few important notes about operator new
and operator delete
:
- The C++ standard requires that a valid pointer is returned even if the size passed to it is 0.
- There's also
operator new[]
andoperator delete[]
, so don't forget about overloading those. - Derived classes inherit
operator new
and its brethren, so make sure to override those.
In Effective C++, item 8, Scott Meyers includes some pseudocodish examples:
void * operator new(size_t size) // your operator new might
{ // take additional params
if (size == 0) { // handle 0-byte requests
size = 1; // by treating them as
} // 1-byte requests
while (1) {
attempt to allocate size bytes;
if (the allocation was successful)
return (a pointer to the memory);
// allocation was unsuccessful; find out what the
// current error-handling function is (see Item 7)
new_handler globalHandler = set_new_handler(0);
set_new_handler(globalHandler);
if (globalHandler) (*globalHandler)();
else throw std::bad_alloc();
}
}
void operator delete(void *rawMemory)
{
if (rawMemory == 0) return; // do nothing if the null
// pointer is being deleted
deallocate the memory pointed to by rawMemory;
return;
}
For more information, I'd definitely pick up Effective C++.

rlbond
- 65,341
- 56
- 178
- 228
-
so, would I just put that in a header and reference that header in all of my files? – Steve Apr 17 '10 at 21:13
-
Well, you'd put the definitions in a source file, but yes. – rlbond Apr 17 '10 at 21:22
-
just a small footnote: you can also define an `operator new(size_t count, size_t alignment)` so you can explicitly pass the alignment as an argument to operator new. This would be called as `new (alignment) AlignedType` – user666412 Jul 14 '15 at 14:37
-
@user666412 be aware that this conflicts with the signature for placement new. A better one would be operator new(size_t count, size_t address, size_t alignment) – Tom Lint Feb 15 '16 at 16:14
-
@Tom Lint .. isn't the signature for placement new a `(size_t, void *)`? – user666412 Feb 15 '16 at 17:43
-
@user666412 You are correct. My example signature should've been operator new(size_t count, void * address, size_t alignment) – Tom Lint Feb 25 '16 at 14:28
3
new
is required to return a pointer [...] suitably aligned so that it can be converted to a pointer of any complete object type
(§3.7.3.1 of the standard).
FWIW, C++ 0x will add an alignof
that will tell you the alignment necessary for a particular type.

Jerry Coffin
- 476,176
- 80
- 629
- 1,111
-
3Unfortunately, for some reason I've never really understood, compilers don't generally apply this rule for 128-bit SIMD types. They're typically still `new`'ed with 8-byte alignment I believe. – jalf Apr 17 '10 at 21:54
-
@jalf: two reasons: (1) the more aligned allocations are, the greater the allocation overhead per block. If you make a lot of 17-byte allocations, you'd see a difference between 16-aligning them and only 4-aligning them. (2) (GNU-specific), glibc makes fewer platform-specific assumptions than GCC, and doesn't really know or care what the biggest type is that some compiler on a system might support. But GCC "wants" to pass malloc straight to glibc, not add its own alignment mechanism, with even more overhead than malloc doing it. I read an interesting public argument about it somewhere. – Steve Jessop Apr 17 '10 at 22:54
-
... finally, the compiler could in theory choose to just align calls to `new SIMD_Type`, avoiding the overhead on all allocations over 15 bytes. But that would still be wrong, because if you're going to do that then you should also similarly align calls to `new char[sizeof(SIMD_Type)]`. The consensus is to pretend that SIMD types aren't "proper builtin types", they're special things that must be allocated specially. – Steve Jessop Apr 17 '10 at 22:57