e3d_alive2 wrote:i was thinking of implementing it either as overloading operator new or using placement new, whatever will work
If you are only implementing a custom allocator then I think you want operator-new as that is specifically for allocation, whereas placement-new is specifically for placement. You would not typically use placement-new except when you want an object constructed at a particular memory address, say if some other process/hardware expects a certain object at a specific address. It is important to keep a distinction between allocation and placement.
In any case, I would not recommend overloading operator new. According to the standard, you can only overload operator new in the global or class scope. Seeing as this would be specifically for CEGUI, you do not want to pollute the global scope. However there are far so many classes that overloading each class' operator new would be a maintenance nightmare. So you are basically left with two options: 1) replace all new/delete calls within CEGUI with calls to a CEGUI allocate/deallocate function/manager or 2) override operator new/delete on a base class and force all CEGUI classes to inherit from them.
Personally I like #1 because there is no coupling between the class and its allocator. The client is free to mix/match allocators based on the needs of the application or each individual class, and can be easily swapped with other allocators should those needs change. I believe the standard library also uses this approach.
I do like this idea of being able to easily implement custom allocation schemes. It can used to debug/trace allocation/deallocation bugs, implement memory pools, group related objects in memory, etc.
edit: moved this thread to the Library Development forum.