Is there a commonly accepted-as-safe approach to wrapping malloc
in a function in C++? What I am attempting to do is allocat arbitrarily sized blocks of memory for holding the output of a function that writes binary values into a fixed size buffer (ie: machine instructions). The approach I am currently using is like so:
class voidp {
void *p;
public:
voidp (void *pp) : p (pp) {}
template<class T> operator T *() { return (T *) p; }
};
When converting C to C++, you can define malloc like this:
inline voidp
mymalloc (size_t size)
{
return malloc (size);
}
#define malloc mymalloc
In many cases, it seems like explicit casts to (void*)
(at least in the case of my compiler) are not allowed, and I must use the template-based approach above.
Is this approach safe, and are there any implications with respect to the "rule of three" (ie: are there any constructors I need to disable or explicitly define/overload)?
Thank you.
References
- My Rant on C++'s operator new - Punching a Whole in the Type System, Accessed 2014-09-05,
<http://www.scs.stanford.edu/~dm/home/papers/c++-new.html>
- Solve the memory alignment in C interview question that stumped me, Accessed 2014-09-05,
<https://stackoverflow.com/questions/227897/solve-the-memory-alignment-in-c-interview-question-that-stumped-me>
Edit
The reason I am doing this is because I'm trying to use something potentially better than just allocating a block of characters via void* buffer = new char[100]
. To further elaborate, I am writing some lower-level code that, against my recommendations, must be written in C++, not pure C. I am also required to have dynamic memory allocation methods that create chunks of memory on the heap that are 16-byte, 32-byte, and 64-byte aligned, like in the example below for 16-byte alignment.
{
void *mem = malloc(1024+15);
void *ptr = ((uintptr_t)mem+15) & ~ (uintptr_t)0x0F;
memset_16aligned(ptr, 0, 1024);
free(mem);
}
My application literally creates group of low level machine instructions in blocks which must be 16/32/64 byte aligned (or it will trigger a CPU-level error), and then passes them off to an on-board DSP chip, which runs them as actual instructions, not just input data.