I tried to use Xerces with the pluggable MemoryManager and I discovered that on several occasions objects are instantiated with the global new operator that does not use the memory manager. Here are some of those cases:
* initializing the EncodingValidator in EncodingValidator.cpp * creating a DOMImplementationListImpl in DOMImplementationImpl.cpp and DOMImplementationRegistry.cpp * creating a DOMNodeListImpl in DOMNodeImpl.cpp * creating a DOMDocumentTypeImpl in DOMImplementationImpl.cpp * ... In our code we essentially forbid the use of plain global "new" so the above cases blow up when Xerces is linked against our codebase. To my understanding the pluggable memory manager is used either: * by making classes derive from the XMemory class which overloads new and delete, or * by using the global overloaded placement new operators that take a DomDocument(Impl) object The problem classes mentioned above are not derived from XMemory but occasionally get instantiated with a plain "new" operator instead of the placement "new"-s. I have a fix that makes those classes inherit the XMemory class, and thus get instantiated with the global memory manager. That caused some problems because on some occasions the global placement "new"-s were shadowed by the Xmemory member "new"-s which produced unexpected results. The solution was to force the use of the global new (::new) to avoid wrong resolving of operator calls. Was there any reason why the classes above do not inherit from XMemory in the first place? On a broader note, is there a particular reason why not have a placement new operator that takes a MemoryManager instance? Perhaps deallocation issues? Thanks, Lyublena
