[ http://issues.apache.org/jira/browse/XERCESC-1380?page=comments#action_61027 ] David Bertoni commented on XERCESC-1380: ----------------------------------------
> So anyway why do you need to define that extra delete operator? Because the C++ standard requires it, for the desired run-time behavior. From 5.3.4.17: "If any part of the object initialization described above terminates by throwing an exception and a suitable deallocation function can be found, the deallocation function is called to free the memory in which the object was being constructed, after which the exception continues to propagate in the context of the new expression. If no unambiguous matching deallocation function can be found, propagating the exception does not cause the object's memory to be freed. [Note: This is appropriate when the called allocation function does not allocate memory; otherwise, it is likely to result in a memory leak. ]" and 5.3.4.19: "A declaration of a placement deallocation function matches the declaration of a placement allocation function if it has the same number of parameters and, after parameter transformations (8.3.5), all parameter types except the first are identical. Any nonplacement deallocation function matches a nonplacement allocation function. If the lookup finds a single matching deallocation function, that function will be called; otherwise, no deallocation function will be called." > The check could be as follows: > > #if !defined(XML_BORLAND) && !defined(NO_DELETE_OVERLOAD) > ... > #endif Yes, the code could be more portable for older, non-compliant compilers. > FYI, the code compiles just fine without operator. But does it exhibit the correct run-time behavior? > Unneccessary definition of extra delete operator causes compiler error > ---------------------------------------------------------------------- > > Key: XERCESC-1380 > URL: http://issues.apache.org/jira/browse/XERCESC-1380 > Project: Xerces-C++ > Type: Bug > Versions: 2.6.0 > Environment: Solaris 2.8 with compiler SPARCompiler 4.2 > Reporter: Maciek Samsel > > So anyway why do you need to define that extra delete operator?: > //The Borland compiler is complaining about duplicate overloading of > delete > #if !defined(XML_BORLAND) > /** > * This method provides a matching delete for the placement new > * > * @param p The pointer to the allocated memory > * @param memMgr An application's memory manager > */ > void operator delete(void* p, MemoryManager* memMgr); > #endif > SPARCompiler 4.2 (as probably a few others) does not recognize that operator > as valid and report an error. > Please make appropriate macro declarations (not only for Borland as it is > now) in platform specific files as well as conditional generation check in > files: > xerces-c-src_2_6_0/src/xercesc/util/XMemory.hpp > xerces-c-src_2_6_0/src/xercesc/util/XMemory.cpp > The check could be as follows: > #if !defined(XML_BORLAND) && !defined(NO_DELETE_OVERLOAD) > ... > #endif > FYI, the code compiles just fine without operator. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
