http://marc.theaimsgroup.com/?l=xerces-c-dev&m=107349519306035&w=2
AFAICS, VC++ (2003) doesn't handle overloading of operator new properly. The XMemory class overloads placement new for allocating XMemory objects using a memory manager:
void* operator new(size_t size, MemoryManager* memMgr);
but the STL uses placement new, where the second argument is a void pointer:
void* operator new(size_t size, void* p);
I haven't checked, but I believe the correct behaviour (according to the C++ standard) should be that the original placement new (with void pointer) remains visible. This appears to be what happens in the gcc (3.4.3), but not in VC++. It seems that overloading new for a particular class obscures all of the original global overloadings of new with respect to that class (even when not all of the versions of new have been overloaded in the class). The easy workaround is to copy any of the original global definitions which haven't already been overloaded. In the case of the XMemory class, the void* variant of placement new can be overloaded using the original definition:
void* operator new(size_t size, void* p) {return p;}Now, I seem to have solved the problem... but was it actually safe to use XMemory objects in STL containers in the first place?
Sam
----- Original Message ----- From: "Sam Lindley" <[EMAIL PROTECTED]>
To: <xerces-c-dev@xml.apache.org>
Sent: Wednesday, December 22, 2004 1:33 PM
Subject: XMLURL memory allocation problem
The following code:
#include <vector> #include <xercesc/util/XMLURL.hpp>
using namespace std; XERCES_CPP_NAMESPACE_USE
int main() { vector<XMLURL> urls(1, XMLURL()); return 0; }
fails to compile under Visual C++ 2003 (VC_7_1) using xerces-c 2.6.0. It gives the error:
C2665: 'xercesc_2_6::XMemory::operator new' : none of the 3 overloads can convert parameter 2 from type 'void *'
Apparently the same code compiles fine under gcc 3.4.3 and xerces-c 2.6.0. The same problem occurs with XMLUri (and presumably any class derived from XMemory). If vector is changed to list, then it compiles.
Any suggestions?
Sam
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
