> > 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.
> Just out of curiousity, can you provide an example of where this
> occurred in the Xerces-C code?
One of the cases was the following initialization in DomDocumentImpl.cpp, the
DOMDeepNodeListImpl object was initialized with the wrong new operator:
XMLSize_t id = fNodeListPool->put((void*) rootNode, (XMLCh*) tagName, 0, new
(this) DOMDeepNodeListImpl(rootNode, tagName));
> > Was there any reason why the classes above do not inherit from XMemory
> > in the first place?
> Just inheriting from XMemory isn't always the right fix. In some cases,
> there may be an available MemoryManager instance, either as a function
> parameter or as a class member. It may also have been done that way to
> avoid multiple inheritance, particularly in the DOM implementation classes.
In the cases I encountered there didn't seem to be an instance of a memory
manager, except for XMLPlatformUtils::fgMemoryManager but there isn't a global
new operator that takes this one as an argument, thus the code for Xmemory::new
would have been repeated.
As for the multiple inheritance, it's used all over the place so I doubt it's
that :)
