Defining custom free() within a class while still using cstdlib free

Question

I'm creating a custom memory allocator on top of the cstdlib malloc() and free() functions (for performance reasons). The allocator is within a simple class that stores a few memory buffers and miscellaneous parameters. I would like to name the method for freeing memory free(), however I need to still be able to use cstdlib's free() from within the class.

#include <cstdlib>

inline void cstdlib_free(void * M){ free(M); } // Works, but is ugly!

class MyAllocator{

    /* ... */

    // Does internal class operations; Does NOT use stdlib's free 
    free(void * _Memory){ /* ... */ }

    // Frees buffers to system memory; USES stdlib's free
    clear(void){
        /* ... */
        cstdlib_free(Buff); // THIS is what I want to change
        /* ... */
    }
};

For the moment, I solved this by creating a wrapper for cstdlib's free(), but I can't help but think there must be a better solution (I also don't want to rename the class's free() method, as I wanted the names to be consistent). I was hoping for a solution along the lines of the first answer of this question, that is, using the base class of cstdlib to access free().

Does C++ provide any method to access the standard C functions as a class structure? Is there some way I can tell the compiler I want to use the scope directly under the class declaration (without it being its superclass, which in this case does not even exist!)?

I *think* that prepending with `::` specifies "from the global namespace", but I could be wrong, so `::free` will do that. I think. — slugonamission, Feb 22 '13 at 00:38
@slugonamission That's exactly what I was looking for! Much nicer then my wrapper. Thanks! — André Harder, Feb 22 '13 at 00:47
Most memory allocators are very good. Your custom allocator may be slower than the cstdlib version. Always measure before and after optimizing. — brian beuning, Feb 22 '13 at 00:54
When I see this: `for performance reasons`. 1) I would note that in C++ we use new/delete and thus changing malloc/free is unlikely to improve any performance. 2) The general purpose allocator may be general purpose but it is already very efficient (and had 10+ years of being optimized (and tested for correctness) thus beating it is going to be hard). 3) If you have some very specific allocation requirements you may want to look at [allocators](http://www.cplusplus.com/reference/memory/allocator/) used by the standard libraries this may be an easier route to get performance enhancements. — Martin York, Feb 22 '13 at 01:01
The allocator is for fixed sized blocks, where I expect something on the order of a couple thousand concurrently allocated addresses that are completely swapped millions of times (but maintaining a relatively constant memory usage). My allocator is ~2x faster than malloc/free (at least against the standard VS allocator on release mode, ~10x in debug mode). I'll take a look at the other allocators, perhaps there's something more effective then cstdlib's implementation in my circumstances. — André Harder, Feb 22 '13 at 02:31

score 2 · Accepted Answer · answered Feb 22 '13 at 00:59

Yes, the original free is accessible as std::free in any context. If you want to be paranoid, add another qualifier and use ::std::free.

::free takes it from the global namespace, which should be the same function, but std:: is preferred. ::free is not guaranteed to exist unless you #include <stdlib.h> rather than <cstdlib>.

Defining custom free() within a class while still using cstdlib free

1 Answers1