CLHEP VERSION Reference Documentation
   
CLHEP Home Page     CLHEP Documentation     CLHEP Bug Reports

ZMuseCount.cc
Go to the documentation of this file.
1 // ----------------------------------------------------------------------
2 //
3 // ZMuseCount.cc - utility class for use in reference-counting
4 //
5 //
6 // History:
7 // 19-Sep-1997 WEB Design stolen, and code adapted, from pp 70-73 of
8 // Koenig & Moo: "Ruminations on C++" (1996)
9 //
10 // ----------------------------------------------------------------------
11 
12 
13 #ifndef ZMUSECOUNT_H
14  #include "CLHEP/RefCount/ZMuseCount.h"
15  #include "CLHEP/RefCount/ZMuseCount.icc"
16 #endif
17 
18 
20 
21  bool result = ( ! only() );
22 
23  if ( result ) {
24  --*p;
25  p = new int(1);
26  }
27 
28  return result;
29 
30 } // makeonly()
31 
32 
33 bool ZMuseCount::reattach( const ZMuseCount & u ) {
34 
35  ++*u.p;
36 
37  bool result = ( --*p == 0 );
38  if ( result )
39  delete p;
40 
41  p = u.p;
42  return result;
43 
44 } // reattach()
a
@ a
Definition: testCategories.cc:125
ignore
always safe to ignore
Definition: mechanics_ZMx.txt:125
logMessage
if another namely the one associated with the parent class of x s class Finally if it wishes a passes that text to the and b returns that function s result as its own result x logMessage() logMessage() is a virtual member function of ZMexception and of exception classes descended from ZMexception. logMessage() is responsible for formatting the complete text of the exception being logged
ZMuseCount::reattach
bool reattach(const ZMuseCount &u)
Definition: ZMuseCount.cc:33
b
@ b
Definition: testCategories.cc:125
logged
if should always be reported to the software s developers and or maintainers Using handlers In the Exceptions a handler is the term for an instance of a class that processes a ZMthrow n exception A handler is responsible for having the exception instance logged
Definition: mechanics_ZMx.txt:168
ZMthrow
ZMthrow event sequence W E Dec These notes document the sequence of significant events set into motion by execution of a single ZMthrow(). A number of details are elided for the sake of clear exposition. 1. ZMthrow(usersException) ZMthrow() is a macro. It expands mainly into a call of ZMthrow_()
events
typically not worth logging since it s probably just a temporary placeholder ZMexINFO In the normal course of events
Definition: mechanics_ZMx.txt:132
thus
thus
Definition: mechanics_ZMx.txt:328
zmex::ZMerrno
ZMerrnoList ZMerrno
Definition: Exceptions/ZMerrno.h:122
is
HepRotation and so forth isNear() norm2() rectify() static Rotation row1 row4(To avoid bloat in the code pulled in for programs which don 't use all these features, we split the implementation .cc files. Only isNear() goes into the original Rotation.cc) --------------------------------------- HepAxisAngle and HepEulerAngles classes --------------------------------------- These classes are very useful and simple structures for holding the result of a nice intuituve decomposition of a rotation there is no longer much content in the distinct ZOOM PhysicsVectors library The only content left in the library is the object files representing the various Exception objects When we build the CLHEP classes for the ZOOM we will set up so as to use ZOOM SpaceVector is(but we can disable namespace usage and most of our users do so at this point). What I do is leave Hep3Vector in the global namespace
single
#define single(obj)
Definition: excDblThrow.cc:26
takeCareOf
ZMthrow event sequence W E Dec These notes document the sequence of significant events set into motion by execution of a single passing on the hereinafter known simply as together with the line number and file name from which the macro is invoked It is mandatory that x be of a type derived from class ZMexception::The result of or b ignored as the macro s final act and then calls x thus initiating x s handling and logging the copy is made as indicated above This code is identical to the code returned by and to invoke that handler s takeCareOf() method
used
When exceptions are the ZMthrow macro looks we know the try part will throw why not just consider how ZMthrow is typically used
Definition: whyZMthrowRethrows.txt:25
ignored
must always be logged and never be ignored
Definition: mechanics_ZMx.txt:160
emit
if another namely the one associated with the parent class of x s class Finally as documented above and b returns that function s result as its own result this method calls flag into the name of the handler being used together with the value of the throw ignore flag Based on filtering it calls the and to invoke that logger s emit() method
handling
The given behavior will apply to any exceptions ZMthrow n after the handler has been established Available handlers Here is a list of the five standard handlers that are defined via the Exceptions package Each is accompanied by a brief description of its after handling
Definition: mechanics_ZMx.txt:206
one
@ one
Definition: testCategories.cc:136
code
Signatures of Hep3Vector::rotate For equivalent ZOOM axis There is no harm in leaving this axis CLHEP has implemented a first forming an identity then rotating that by axis and I leave the CLHEP code alone people are of course free to use the ZOOM originated method with signature which I believe will be faster Return types for rotateZ CLHEP and PhysicsVectors each have these three and they are identical except that the ZOOM version returns a reference to while in CLHEP they return void Having methods that alter an object return a reference to that object is convenient for certain chained and costs nothing I don t wish to potentially break ZOOM user code for no good so I have made these CLHEP method conform to this convention There are a couple of other CLHEP rotate and which use the void return but since these methods or signatures don t appear in the original ZOOM this can t break any code
Definition: minorMergeIssues.doc:115
criteria
if another namely the one associated with the parent class of x s class Finally as documented above and b returns that function s result as its own result this method calls flag into the name of the handler being used together with the value of the throw ignore flag Based on filtering criteria
Definition: ZMthrow_event_sequence.txt:90
logging
typically not worth logging since it s probably just a temporary placeholder ZMexINFO In the normal course of here is news worth logging
Definition: mechanics_ZMx.txt:132
ZMuseCount
Definition: Exceptions/CLHEP/RefCount/ZMuseCount.h:17
any
this formatted text is the function s string result this method sends the formatted string s to the ostream destination specified when the logger was instantiated as its a code describing if any
Definition: ZMthrow_event_sequence.txt:148
not
if not
Definition: ZMthrow_event_sequence.txt:51
handleMe
ZMthrow event sequence W E Dec These notes document the sequence of significant events set into motion by execution of a single passing on the hereinafter known simply as together with the line number and file name from which the macro is invoked It is mandatory that x be of a type derived from class ZMexception::The result of or b ignored as the macro s final act and then calls x handleMe()
ZMuseCount::makeonly
bool makeonly()
Definition: ZMuseCount.cc:19
type
Signatures of Hep3Vector::rotate For equivalent ZOOM axis There is no harm in leaving this axis CLHEP has implemented a first forming an identity then rotating that by axis and I leave the CLHEP code alone people are of course free to use the ZOOM originated method with signature which I believe will be faster Return types for rotateZ CLHEP and PhysicsVectors each have these three and they are identical except that the ZOOM version returns a reference to while in CLHEP they return void Having methods that alter an object return a reference to that object is convenient for certain chained and costs nothing I don t wish to potentially break ZOOM user code for no good so I have made these CLHEP method conform to this convention There are a couple of other CLHEP rotate and which use the void return type
Definition: minorMergeIssues.doc:113
Brown
ZMthrow event sequence W E Brown
Definition: ZMthrow_event_sequence.txt:2
above
In the example above
Definition: mechanics_ZMx.txt:49
Next
ZMthrow event sequence W E Dec These notes document the sequence of significant events set into motion by execution of a single passing on the hereinafter known simply as together with the line number and file name from which the macro is invoked It is mandatory that x be of a type derived from class ZMexception::The result of or b ignored as the macro s final act and then calls x thus initiating x s handling and logging Next
Definition: ZMthrow_event_sequence.txt:33
Finally
ZMthrow event sequence W E Dec These notes document the sequence of significant events set into motion by execution of a single passing on the hereinafter known simply as together with the line number and file name from which the macro is invoked It is mandatory that x be of a type derived from class ZMexception::The result of or b ignored as the macro s final act and then calls x thus initiating x s handling and logging the copy is made Finally
Definition: ZMthrow_event_sequence.txt:37
result
this formatted text is the function s string result this method sends the formatted string s to the ostream destination specified when the logger was instantiated as its result
Definition: ZMthrow_event_sequence.txt:148
use
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these and where relevant describe the resolutions More detailed documents describe more minor issues General Approach As agreed at the June CLHEP the approach is to combine the features of each ZOOM class with the corresponding CLHEP class expanding the interface to create a single lingua franca of what a I have placed almost all the new features in a second section of the and have created separate cc files for sensible subsets of the methods In if a program uses only the methods found in the original CLHEP very little additional code is linked in Classes The corresponding classes I am not giving up on it eventually being in use
Definition: keyMergeIssues.doc:62
ZMex
Introduction to the Use of Zoom Exceptions W E last revised Jan Introduction This summary describes the mechanics decided on for creating and throwing a ZMexception as implemented by the zoom Exceptions package Note that all public C symbols used within this Exceptions class begin with the unlikely prefix ZMex(or, in the case of the preprocessor, "ZMEX") in order to help avoid namespace pollution. For example
usersException
ZMthrow event sequence W E Dec These notes document the sequence of significant events set into motion by execution of a single passing on the usersException
Definition: ZMthrow_event_sequence.txt:13
what
this formatted text is the function s string result this method sends the formatted string s to the ostream destination specified when the logger was instantiated as its a code describing what
Definition: ZMthrow_event_sequence.txt:148
ZMthrow_
ZMthrow event sequence W E Dec These notes document the sequence of significant events set into motion by execution of a single passing on the hereinafter known simply as together with the line number and file name from which the macro is invoked It is mandatory that x be of a type derived from class ZMexception::The result of ZMthrow_() is a code indicating whether x is to be a) thrown
set
set(pkginclude_HEADERS itos.h) INSTALL(FILES $
Definition: Cast/Cast/CMakeLists.txt:2
zmex::ZMexERROR
@ ZMexERROR
Definition: CLHEP/Exceptions/ZMexSeverity.h:46
This
Signatures of Hep3Vector::rotate For equivalent ZOOM axis There is no harm in leaving this axis CLHEP has implemented a first forming an identity then rotating that by axis and I leave the CLHEP code alone people are of course free to use the ZOOM originated method with signature which I believe will be faster Return types for rotateZ CLHEP and PhysicsVectors each have these three and they are identical except that the ZOOM version returns a reference to while in CLHEP they return void Having methods that alter an object return a reference to that object is convenient for certain chained and costs nothing I don t wish to potentially break ZOOM user code for no good so I have made these CLHEP method conform to this convention There are a couple of other CLHEP rotate and which use the void return but since these methods or signatures don t appear in the original ZOOM this can t break any so I leave the void return type alone for those After discussion with A P and I have modified the return types of other CLHEP methods which return void and would by the same reasoning be better returning *this These include rotate and boost methods in LorentzVector h HepLorentzVector explicit and leads to division by zero if this vector has which takes very little time I think the zoom implementation is therefore better This
Definition: minorMergeIssues.doc:141
behavior
The given behavior will apply to any exceptions ZMthrow n after the handler has been established Available handlers Here is a list of the five standard handlers that are defined via the Exceptions package Each is accompanied by a brief description of its behavior
Definition: mechanics_ZMx.txt:188
for
for(n=1 ;n< 98 ;n++)
Definition: JamesRandomSeeding.txt:34
x
ZMthrow event sequence W E Dec These notes document the sequence of significant events set into motion by execution of a single passing on the hereinafter known simply as x
Definition: ZMthrow_event_sequence.txt:13
classes
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these and where relevant describe the resolutions More detailed documents describe more minor issues General Approach As agreed at the June CLHEP the approach is to combine the features of each ZOOM class with the corresponding CLHEP class expanding the interface to create a single lingua franca of what a I have placed almost all the new features in a second section of the and have created separate cc files for sensible subsets of the methods In if a program uses only the methods found in the original CLHEP classes
Definition: keyMergeIssues.doc:29
which
the naive Gaussian approximation is inaccurate at a level which
Definition: validation.doc:329
standardHandling
if another namely the one associated with the parent class of x s class Finally as documented above and b returns that function s result as its own result this method calls standardHandling() with arguments giving the exception x together with a throw/ignore flag. takeCareOf() returns the same result given as the result of standardHandling(). 6. standardHandling(x
this
any side effects of that construction would occur twice The semantics of throw on the other are that x is not constructed an extra time The macro used achievs this
Definition: whyZMthrowRethrows.txt:41
name
user code seldom needs to call this function directly ZMerrno whether or not they are still recorded ZMerrno whether or not they are still since the user counter was last ZMerrno name() gives the(string) name of the latest recorded exception
logMe
if another namely the one associated with the parent class of x s class Finally as documented above and b returns that function s result as its own result this method calls flag into the name of the handler being used together with the value of the throw ignore flag Based on filtering it calls the logMe() function associated with x 's class. Finally
with
this we validated with
Definition: validation.doc:308
are
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these and where relevant describe the resolutions More detailed documents describe more minor issues General Approach As agreed at the June CLHEP the approach is to combine the features of each ZOOM class with the corresponding CLHEP class expanding the interface to create a single lingua franca of what a I have placed almost all the new features in a second section of the and have created separate cc files for sensible subsets of the methods In if a program uses only the methods found in the original CLHEP very little additional code is linked in Classes The corresponding classes are
Definition: keyMergeIssues.doc:61
ZMuseCount::only
bool only()