[ http://issues.apache.org/jira/browse/XERCESC-1380?page=comments#action_61252 ] Maciek Samsel commented on XERCESC-1380: ----------------------------------------
"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. Non-compliant? Are quoting a new, revised requirements or old ones. Do you suggest that SPARCompiler 4.2 was not compliant with C++ specs of its days? That would be harsh suggestion and I would suggest caution since most of C++ commercial stuff on Solaris for years was developed with one of SPARCompiler's. What are you going to do when new C++ extensions will appear? Are you going to give the same feedback voiding previous compliance and stopping to help with support for number of older compilers? I thought that Xerces wanted some subset of C++... otherwise why don't you use STL and generic programming rather than those custom and rather obsolete types and techniques these days. > FYI, the code compiles just fine without operator. >But does it exhibit the correct run-time behavior? Do you offer any test suite/unit tests for Xerces? Usually, they are part of a project these days... well at least in Java JUnit is used extensively. To tell you truth I would assume that it does as a logical conclusion. Since compiler complains (error) about unknown compiler then it does not intend to use it. Am I correct or is these unclear? By the way, I believe that saw two placement delete operators defined in the same file. One was accepted by the compiler. > 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]
