[ http://issues.apache.org/jira/browse/XERCESC-1380?page=comments#action_61264 ] David Bertoni commented on XERCESC-1380: ----------------------------------------
I'm having trouble understanding the rather angry tone of your comments. I am simply trying to respond to your questions. Do you really feel the need to attack my responses when all I'm trying to do is answer your questions? > Non-compliant? Are quoting a new, revised requirements or > old ones. I'm quoting the only C++ standard the exists -- ISO/IEC 14882. > 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. I'm only suggesting it's not compliant with the C++ standard, and nothing else. There was nothing "harsh" in my reply. > What are you going to do when new C++ extensions will > appear? We won't use C++ "extensions" -- we try to use code that complies with the standard. Since a C++ standard exists, and most modern compilers conform to it, I think that's a reasonable approach. > Are you going to give the same feedback voiding previous > compliance and stopping to help with support for number of > older compilers? My feedback was not an attempt to "void" previous compliance, and I don't understand how you could misconstrue my responses as you have. In fact, when users provide information regarding a problem with the code on a particular compiler, we do our best to fix the code so it will work on that compiler. > 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. There has been discussion of this question on the list. You are welcome to search through the archives for more information. In particular, there was a discussion about using the container classes in the standard library (aka STL). > 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. Yes, there is a sanity test for the parser. See the perl script sanityTest.pl in the scripts directory. > 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]
