[ http://issues.apache.org/jira/browse/XERCESC-1323?page=comments#action_57386 ] Robert Buck commented on XERCESC-1323: --------------------------------------
Hi Alby, With regards to your last comment, the problem is that the result will be object slicing. Users will not be able to catch the specific exception type. Compilers are tending to become more stringent with regards to this specific behavior. Microsoft's support for this has come and gone over the years, but now MS is following the spec more closely. Other compilers, especially those that have EDG based front ends (Intel), will have similar issues. The issue will only increase as each compiler becomes more ISO C++ compliant. I have authored the diagnostics and exception handling framework in MATLAB, and in order to guarantee consistent, correct behavior on the following compilers: HP aCC Sun CC g++ cl.exe ecc (7.1 is EDG based) we had to observe the following ground rules: a. public default constructor b. public copy constructor c. public destructor d. the above for all super classes e. throw-type, never throw-new f. catch by reference, never by pointer, nor by value Given these ground rules, it would make little sense to me for Xerces-C exception classes to derive from XMemory. There is only one case I can think of where you'd want to heap allocate an exception object... For illustration let me refer back to what I wrote for the C++ exception classes in MATLAB. In order to support causation semantics (similar, but superior to what Java has), I did need to heap allocate the chained exception. However in this case, simply using a macro, that defines all the required operator-new and operator-delete static methods for a class was sufficient. The [new and delete] operators would, of course, call the implementation defined memory management functions. The exception classes have a link time dependency upon the exported memory management symbols, and a compile time dependency upon those abstractions, but the memory management abstractions only internally have a compile time dependency; the exported header declares no such dependency. So a side benefit of this strategy is that the compile time dependency between memory management and exception handling can be broken, benefits which are academic. My general suggestions are as follows: 1. Create a common base class for all exceptions, perhaps called XercesThrowable 2. Do not have XercesThrowable, nor any other exception type, inherit from XMemory. 3. Follow similar guidelines, as shown above in [a-f]. 4. Define a macro (you probably already have one) that defines all twelve (12) static inline new and delete operators, according to ISO C++ § 18.4.1, § 3.7.3, as well as the replacement functions in § 17.4.3.4. For platforms that do not support std::nothrow, you can reduce this to eight (8) methods. 5. Use the macro defined in [4] in each exception class. If you want a copy of the C++ standard, email me directly your email address at Progress, or a private email, and I will send it to you privately. > CLONE -XMemory related warning > ------------------------------ > > Key: XERCESC-1323 > URL: http://issues.apache.org/jira/browse/XERCESC-1323 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: Nightly build (please specify the date) > Environment: Operating System: Windows NT/2K > Platform: PC > Reporter: Robert Buck > > When building (VS.NET 2003) my app with latest CVS snapshot (20031120171656) > I > keep getting warning (level 4) : > D:\Utils\xerces\src\xercesc\internal\XSerializeEngine.hpp(664) : warning > C4673: > throwing 'xercesc_2_4::XSerializationException' the following types will not > be > considered at the catch site > D:\Utils\xerces\src\xercesc\internal\XSerializeEngine.hpp(664) : warning > C4671: 'XMemory' : the copy constructor is inaccessible > I'm not sure if it is really safe to ignore this warning ... -- 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]
