views:

58

answers:

1

Hi Guys.

This is a design question, assuming C++ and a reference counted object hierarchy. A lot of classes in my codebase derive from a common base class (ObjectBase), which implements retain() and release() methods to increase and decrease the reference count of an object instance.

Every instance of an object may be created on the stack or on the heap, using a number of user definable memory allocators. In order for the object instance to commit suicide (delete this) in the release() method if the retainCount reaches 0, the instance must know which allocator it has been constructed with.

At the moment, I am allocating memory for an object instance using an arbitrary allocator, then call placement new to construct the object instance and call a setAllocator() method on the object to set the allocator it has been created with. If the object has been constructed on the stack, the allocator is set to NULL and release() will not call delete. This process is very redundant and potentially error prone (memory leaks, if I forget to call setAllocator, etc...) Ideally I would want to make this a one-step process like this:

Object* o = myPoolAllocator.allocate<Object>(constructor arguments... );

But this makes it very difficult to support and arbitrary number of constructor arguments.

I am just looking for ideas on how to solve this problem. I really like the idea of being able to reference count objects without having to rely on a smart pointer, especially since most classes derive from a common base, anyways.

Thanks for your help.

Florian

+1  A: 

Have a look at this article: Overloading New in C++ . You could overload the new operator for ObjectBase so that it takes your allocator as a parameter and does the rest of the job:

void *ObjectBase::operator new(size_t size, Allocator *allocator) {
  void *ptr = allocator->allocate(size);

  // Hack to pre-initialize member before constructor is called
  ObjectBase *obj = static_cast<ObjectBase *>(ptr);
  obj->setAllocator(allocator);

  return ptr;
}

Normally, the operator is supposed to just return a pointer to the allocated memory, but since you need access to the new object to call your setAllocator method, I've included a hack that should (but may not) work. Note that the actual ObjectBase constructor is called after the above function returns, so you should make sure that your constructor does not re-initialize the allocator member.

And then a similar overload for delete:

void ObjectBase::operator delete(void *ptr) {
  ObjectBase *obj = static_cast<ObjectBase *>(ptr);
  obj->getAllocator()->free(ptr);
}

You would then create objects by calling new (allocator) SomeClass(...) where SomeClass derives from ObjectBase.

Edit: One potential problem with this is that you cannot allocate objects on the stack any more, because there is no way to initialize the allocator to NULL without affecting the how the overloaded new works.

Update: There is one last (dirty) hack to get it working with both stack and dynamic allocation. You can make new set a global variable (a class static member would work as well) pointing to the current allocator and the constructor could consume this and reset it to NULL. At all other times, this global will already be NULL so an object constructed on the stack will get a NULL allocator.

Allocator *currentAllocator = NULL;

void *ObjectBase::operator new(size_t size, Allocator *allocator) {
  currentAllocator = allocator;
  return allocator->allocate(size);
}

ObjectBase::ObjectBase() {
  setAllocator(currentAllocator);
  currentAllocator = NULL;
}
casablanca
casablanca, thanks for your fast response and thanks for fixing the source tag in my OT! I have considered a similar method like you suggest, but like you correctly noted, I won't be able to create objects on the stack, anymore. I have thought about checking in the ObjectBase constructor, whether the allocator field points to a valid allocator instance and if not, considering the object to be on the stack. However, this is dangerous business, considering that there is some (although small) chance that the uninitialized allocator field just happens to point to a valid allocator.
FlorianZ
@FlorianZ: See my updated answer for yet another possible hack.
casablanca
@casablanca. That's a pretty good idea, too! My only concern with this is that it's probably not thread-safe. What if a context switch occurs after the operator new returns, but before the constructor gets a chance to consume the currentAllocator variable. If allocations are then executed in the second thread, currentAllocator would then be compromised. Any ideas as to how to make your solution thread-safe?
FlorianZ
To propose a solution to my own question regarding thread-safety. I could potentially use a mutex to lock the CS before assigning currentAllocator and then unlock the same mutex right after currentAllocator has been consumed in the ObjectBase constructor. Any thoughts on that?
FlorianZ
@FlorianZ: I was going to come to that point, i.e. is your program multi-threaded? You can use thread-local storage for the global - that would allow each thread to independently allocate objects without waiting on others. Different compilers (VC++ and gcc) have their own way of specifying thread-local modifiers.
casablanca
@casablanca. Thanks, TLS is a much better idea. My application is multi-threaded to some degree. For low level stuff like memory allocations, I would like to go with a completely thread-safe implementation. My application is also cross-platform, but after doing some research it looks like all my target platforms come with library support for TLS... Thanks again!
FlorianZ