You're really not supposed to do it with macros.

1. Changing the allocator used by the standard library by passing in a special allocator to instantiations of std::vector, std::map, etc.

2. Allocating raw memory elsewhere, and instantiating an object with that memory using the placement syntax for new.

3. Overriding operator new on just a particular class. This does not change the global new; it just means that objects of this class will be allocated with this version of new.

4. Overriding the global definition of new. All objects whose classes do not define their own operator new will be allocated with your own, global new.

More details here: http://en.cppreference.com/w/cpp/memory/new/operator_new

    void* operator new  ( std::size_t count );
    void* operator new[]( std::size_t count );
    void operator delete  ( void* ptr );
    void operator delete[]( void* ptr );

If you do it that way, you do not need to change any of the code that calls new and delete.

And I disagree about the 'relatively' in "I know that in C it is relatively easy to define your own memory management functions"

It is easy to piggy-back on an existing memory allocator, and it is fairly easy to make an implementation that works from a single thread, or an implementation that performs horribly from multiple threads, but it is not easy to make one that performs well from multiple threads and is useful.

[That "and is useful" is from the hacker in me. It is trivial to make what I think is a conforming implementation that multi-threads exceptionally well along the lines of (I am guessing at the prototypes):

    void * malloc(size_t t)            { return NULL;}
    void * calloc(int n, size_t t)     { return NULL;}
    void   free(void *m)               {}
    void * realloc( void *m, size_t t) { return NULL;}

The example I quoted in Python's implementation, though, seems to hold truer - rather than calling malloc whenever it needs more space it allocates buffers and hands out memory from them, reducing the frequency of calls to malloc, and meaning that its garbage collector sometimes can't free as much RAM as you hoped (since there are some nearly-empty buffers that can't be released.) This makes running python instructions which need a little more RAM much faster, at the expense of complexity when RAM is short, of course. And overall the program should be faster, since it has fewer system calls (assuming that the code which hands out RAM is well optimised, which should be possible since it can be much simpler than the system malloc.)

C++ standard meets modern runtimes. Wheee! :-)