Exceptions Package -- Problem Tracking 005: archspec_Exceptions written for outdated g++ Initial Bug Report 5/30/02 ------------------ Version ? WEB discovered that archspec_Exceptions.mk contains g++-specific code that relies on egcs-era default behavior/command-line switches. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ================================================================== - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 5/31/02 ----------------- version ? The necessary replacements are made. ================================================================== 004: Base ZMexception different Initial Bug Report 11/29/01 ------------------ Version 2.0.5 S. Snyder found, when attempting to use the ErrorLogger to log all ZMexceptions by seting that base class' logger to ZMexViaErrlog, that he could not for this base class. The reason is differences in how the base class is set up and how the derived classes are set up via the StandardDefinition macro. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bug Reproduced 12/17/01 -------------- A new test in ErrLogEx package, elxZMlogVia.cc, was created. It does ZMexception::_classInfo.setLogger( ZMexViaErrlog(log) ); instead of setting this up for an intermediate user-defined base class. Indeed, we get "ZMexception::_classInfo" is inaccessible This is exactly as Scott pointed out. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ------------ Scott has pointed out a sequence of a few changes that need to be made; each will be understood and made; the acid test of elxZMlogVia.cc should then work properly. ================================================================== - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified ----------------- version 2.0. The necessary include is inserted. ================================================================== 003: Missing sstream Initial Bug Report 10/8/01 ------------------ Version 2.0.3 MF and WB, when building base releases under gcc, noted that the build was broken by failure to include sstream in ZMexception.h. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bug Reproduced 10/11/01 -------------- This bug was introduced when the new constructor for an exception from an ostringstream was added. Evidently no gcc builds had been done since then. (KAI somehow introduces enough of a forward definition that this works fine under that compiler.) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 10/12/01 ----------------- version 2.0.4 The necessary include is inserted. ================================================================== x002: emit clash Initial Bug Report 5/3/01 ------------------ Version 2.0.1 (Note that 2.0.2 had been released for 2.5 weeks at this point) George Alverson via Paul Russo reports: While building d0scan_qt against t01.43.00 I'm getting a lot of "/d0dist/dist/releases/t01.43.00/include/CLHEP/Vector/ZMxpv.h", line 185: error #133: expected a member name ZMexStandardDefinition (ZMxPhysicsVectors, ZMxpvNotOrthogonal); I've changed a bit of text, but since I don't explicitly include any zoom headers, finding this is going to be a pain. I'm also seeing "/d0dist/dist/releases/t01.43.00/include/Exceptions/ZMexLogger.h", line 202: error #40: expected an identifier virtual ZMexLogResult emit( const ZMexception & x ); It looks like the emit from ZOOM is not protected by a namespace (I have an emit method, also unprotected). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bug Reproduced -------------- This problem appears to be because the user has a method "emit()" which is clashing with the emit() method in the Exceptions package (created by ZMexStandardDefinition). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ------------ This is a user-induced problem, and there exist satisfactory correct ways to use the package without the experiment turning on the zmex namespace. The experiment can turn on the namespace to resolve this problem completely, if desired. ================================================================== 001: Namespace insufficiency Initial Bug Report 3/20/01 ------------------ Version 2.0.1 Scott Snyder reports: This is not a problem at the moment, but it would be a problem if we ever decide to enable namespaces with the zoom packages. With namespaces off, the following compiles: #include "Exceptions/ZMexception.h" ZMexStandardDefinition (ZMexception, Exc_Bad_Bound_Pointer_Delete); If i want to turn namespaces on, compiling with `-DZM_USE_NAMESPACES', i would expect that the following should work: #include "Exceptions/ZMexception.h" ZMexStandardDefinition (zmex::ZMexception, Exc_Bad_Bound_Pointer_Delete); (I do have to remember that `ZMexStandardDefinition' is a macro, so it doesn't live in a namespace). However, the above does not compile. The reason is that the ZMexStandardDefinition macro contains references to names in the zmex namespace that are not namespace-qualified. In fact, i don't know how to get this to compile with namespaces on short of adding using declarations or directives for the zmex names --- and putting those in header files defeats much of the purpose of using namespaces in the first place. The ZMthrow macro has the same issue. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bug Reproduced 4/13/01 -------------- MF sees the problem and has discussed it with PC for a solution. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ------------ Turns out that ZMenvironment.h already contains the tools needed to address this: ZM_QUAL_NAME (space, name) (or QUAL_NAME(space, name)) and ZM_USE_NAMESPACES if necessary. The changes spread thru the StandardDefinitions sequence of macros, however, and will need careful testing. For example, in USER code that does a definition, we must be sure the user can'tr get into trouble for lack of a utility define -- that one seems OK because ZMexception.h includes ZMenvironment.h. In particular, a user can do ZMthrow without ZMexception.h and we must make sure this works. Prior estimate is 1.6: Planning (already done) .2 Coding ZMexception .4 Planning + Coding for ZMthrow .2 Mods to GNUmakefiles to test .1 Testing .4 Documentatin of how to use .2 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Status of repair ---------------- Beginning repair 4/13/01 Planning done Coding ZMexception done Planning + Coding for ZMthrow done - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 4/17/01 ----------------- version 2.0.2 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ================================================================== Template for each bug: xxx: Name Initial Bug Report ------------------ Version 2.x.x - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bug Reproduced -------------- MF sees the problem and has discussed it with PC for a solution. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ------------ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Status of repair ---------------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Status of repair ---------------- * * (in long-running problems might need more than one) * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified ----------------- version x.z - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Ongoing Caveats --------------- * * * ==================================================================