vicente.botet wrote:
I'm not sure I understand you here. Are you saying that other threads may be accessing the array elements during the destruction?
Yes. This is the case I try to solve.
Why not locking the mutex (or whatever you use to synchronize the threads) in the destructor? It will block if another thread is working with the object.
All in all, the overall scheme is as follows:
static void* operator new[] (std::size_t size) { void* p = std::malloc(sizeof(info_t) + gap_size + size); if (p) { new (p) info_t(); static_cast< info_t* >(p)->m_Count = size / sizeof(T);
Are you sure the size given as parameter consider only the user info? Doesn't this size includes any additional part needed by the standard library to know if the the allocation corresponds to a single element or to an array and whatever is needed to call the destructors of all the array elements?
Hmm... Looks like you're right here. The Standard doesn't say what the size will be and at least gcc does add a little to the size. However, if sizeof(T) is big enough, you may not notice this extra increase in size. Well, unless you want to tweak your code for every compiler/platform to take that additional info into account, I don't see how this can be solved. You might want to use an additional argument to the operator new[] to pass the array size twice, but this essentially eliminates the advantage of using the regular operator new. Still, you will be able to use scoped_array, shared_array, etc.