Typedefs | |
| using | documenting.Summary = ======The following table summarizes the guidelines in this document.In all the below,``T``represents the type *pointed to *by the given pointer type.==================================================================Pointer type Ownership Move/Copy Example uses==================================================================``T *``none shallow should be rare, especially as class data``unique_ptr< T >``sole move-transfer return newly created object |
Functions | |
| p | someMemberFunctionOfTypeX () |
| The Standard | Library (ISO C++2011) provides several smart pointer types |
| The Standard available from< memory > inherited from C(deprecated)*``std event | put (std::move(myProdPtr)) |
| in some code it could be surprising or even disastrous for an object to be shared between many owners Try | value_ptr (below) in such a case.``std |
| The stack based allocation of the object s assures that it will not be leaked The following code is never appropriate::void | bad_f () |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns | prematurely (either by calling``return``, or throwing an exception, or by calling something that throws an exception) then the``SomeType``object pointed to by``s``will be leaked.Even if the code written today does not have any chance of doing so |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic::Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be but also might *not *be made Creation of a pointer to base that will be initialized to point to some derived type Creation of a very large one that would require an unreasonable amount of stack space In such a pointer of some type is appropriate **In none of the cases listed above is a bare pointer appropriate **To choose the correct pointer consider the issues of *ownership *and the intended semantics of *copying *Ask the following then use scoped_ptr This will prevent your pointer from being copied accidentally If it makes sense to copy the should the copied pointer *share control of the pointed to object *If then use | shared_ptr (If your object already has an embedded reference count, then use``intrusive_ptr``.) 3.If it makes sense to copy the pointer |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic::Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be but also might *not *be made Creation of a pointer to base that will be initialized to point to some derived type Creation of a very large one that would require an unreasonable amount of stack space In such a pointer of some type is appropriate **In none of the cases listed above is a bare pointer appropriate **To choose the correct pointer consider the issues of *ownership *and the intended semantics of *copying *Ask the following then use scoped_ptr This will prevent your pointer from being copied accidentally If it makes sense to copy the should the copied pointer *share control of the pointed to object *If then use should the act of copying *transfer ownership *to the new pointer If then use auto_ptr This is useful in functions that are | sources (that is,*factory functions *) |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic::Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be but also might *not *be made Creation of a pointer to base that will be initialized to point to some derived type Creation of a very large one that would require an unreasonable amount of stack space In such a pointer of some type is appropriate **In none of the cases listed above is a bare pointer appropriate **To choose the correct pointer consider the issues of *ownership *and the intended semantics of *copying *Ask the following then use scoped_ptr This will prevent your pointer from being copied accidentally If it makes sense to copy the should the copied pointer *share control of the pointed to object *If then use should the act of copying *transfer ownership *to the new pointer If then use auto_ptr This is useful in functions that are to indicate that ownership of the created object that is returned by the call is given to the caller It is useful in functions that are | sinks (such as``art::Event::put``) |
Variables | |
| the word *pointer *should be understood to include *bare pointers *and all sorts of *smart pointers *The most important guideline | is |
| the word *pointer *should be understood to include *bare pointers *and all sorts of *smart pointers *The most important guideline and mean what you say This means that you should use the pointer type that most directly conveys the purpose of the code Writing your code so that it *clearly expresses your intent *takes little extra | effort |
| the word *pointer *should be understood to include *bare pointers *and all sorts of *smart pointers *The most important guideline and mean what you say This means that you should use the pointer type that most directly conveys the purpose of the code Writing your code so that it *clearly expresses your intent *takes little extra and pays large dividends in the future The lifetime of an experiment is quite long The code you write today is likely to be read and modified by you or by someone else many months or years from now If you use a pointer type that does not express the right | intent |
| the word *pointer *should be understood to include *bare pointers *and all sorts of *smart pointers *The most important guideline and mean what you say This means that you should use the pointer type that most directly conveys the purpose of the code Writing your code so that it *clearly expresses your intent *takes little extra and pays large dividends in the future The lifetime of an experiment is quite long The code you write today is likely to be read and modified by you or by someone else many months or years from now If you use a pointer type that does not express the right that later reader is likely to mistake the | purpose |
| the word *pointer *should be understood to include *bare pointers *and all sorts of *smart pointers *The most important guideline and mean what you say This means that you should use the pointer type that most directly conveys the purpose of the code Writing your code so that it *clearly expresses your intent *takes little extra and pays large dividends in the future The lifetime of an experiment is quite long The code you write today is likely to be read and modified by you or by someone else many months or years from now If you use a pointer type that does not express the right that later reader is likely to mistake the and modify your code incorrectly The resulting coding errors are often very difficult to debug A small amount of effort used to select the right type can prevent such troubles This is explained in more detail below Pointer | Types |
| the word *pointer *should be understood to include *bare pointers *and all sorts of *smart pointers *The most important guideline and mean what you say This means that you should use the pointer type that most directly conveys the purpose of the code Writing your code so that it *clearly expresses your intent *takes little extra and pays large dividends in the future The lifetime of an experiment is quite long The code you write today is likely to be read and modified by you or by someone else many months or years from now If you use a pointer type that does not express the right that later reader is likely to mistake the and modify your code incorrectly The resulting coding errors are often very difficult to debug A small amount of effort used to select the right type can prevent such troubles This is explained in more detail below Pointer so that instances can be created to point to objects of various types Smart pointer types differ in their behavior All support *dereferencing *and *member selection *The code below shows the common(but not universal) interface X & | xref = *p |
| X * | xptr = p.operator->() |
| The use this makes sure that code that *calls *this function takes ownership of the newly created object With such an | implementation |
| The use this makes sure that code that *calls *this function takes ownership of the newly created object With such an even code that fails to accept the newly created object does not cause a memory | leak |
| the unnamed unique_ptr object is immediately | deleted |
| the unnamed unique_ptr object is immediately which then deletes the pointed to object ownership is transferred by | copying |
| the unnamed unique_ptr object is immediately which then deletes the pointed to object ownership is transferred by not move semantics The act of copying an auto_ptr empties the original In | C |
| Even though this code calls delete on | s |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly | written |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return | prematurely |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic::Guideline Prefer to put local objects on the stack Less | often |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic::Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases | include |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic::Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be | made |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic::Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be but also might *not *be made Creation of a pointer to base that will be initialized to point to some derived type Creation of a very large | object |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic::Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be but also might *not *be made Creation of a pointer to base that will be initialized to point to some derived type Creation of a very large one that would require an unreasonable amount of stack space In such | cases |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic::Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be but also might *not *be made Creation of a pointer to base that will be initialized to point to some derived type Creation of a very large one that would require an unreasonable amount of stack space In such a pointer of some type is appropriate **In none of the cases listed above is a bare pointer appropriate **To choose the correct pointer | type |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic::Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be but also might *not *be made Creation of a pointer to base that will be initialized to point to some derived type Creation of a very large one that would require an unreasonable amount of stack space In such a pointer of some type is appropriate **In none of the cases listed above is a bare pointer appropriate **To choose the correct pointer consider the issues of *ownership *and the intended semantics of *copying *Ask the following | questions |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic::Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be but also might *not *be made Creation of a pointer to base that will be initialized to point to some derived type Creation of a very large one that would require an unreasonable amount of stack space In such a pointer of some type is appropriate **In none of the cases listed above is a bare pointer appropriate **To choose the correct pointer consider the issues of *ownership *and the intended semantics of *copying *Ask the following then use scoped_ptr This will prevent your pointer from being copied accidentally If it makes sense to copy the | pointer |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic::Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be but also might *not *be made Creation of a pointer to base that will be initialized to point to some derived type Creation of a very large one that would require an unreasonable amount of stack space In such a pointer of some type is appropriate **In none of the cases listed above is a bare pointer appropriate **To choose the correct pointer consider the issues of *ownership *and the intended semantics of *copying *Ask the following then use scoped_ptr This will prevent your pointer from being copied accidentally If it makes sense to copy the should the copied pointer *share control of the pointed to object *If | so |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic::Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be but also might *not *be made Creation of a pointer to base that will be initialized to point to some derived type Creation of a very large one that would require an unreasonable amount of stack space In such a pointer of some type is appropriate **In none of the cases listed above is a bare pointer appropriate **To choose the correct pointer consider the issues of *ownership *and the intended semantics of *copying *Ask the following then use scoped_ptr This will prevent your pointer from being copied accidentally If it makes sense to copy the should the copied pointer *share control of the pointed to object *If then use should the act of copying *transfer ownership *to the new pointer If then use auto_ptr This is useful in functions that are to indicate that ownership of the created object that is returned by the call is given to the caller It is useful in functions that are to indicate that the called function is taking control of the passed object If it makes sense to copy the should the copy manage its own copy of the pointed to object If then use value_ptr Copying a value_ptr creates a *deep copy *of the pointed to object topic::Guideline Use a pointer type only when necessary Choose the type of pointer after considering *object ownership *and *copying semantics *For class data members Please refer to EDM documentation for special issues regarding design of classes used as EDProducts Such classes are subject to restrictions imposed by the art Event Data Model and the persistency system It is very rarely correct to have a class contain a bare pointer as a data member[#] _ This is because a bare pointer does not convey any sense of *ownership *Most data members of a class should be held by *value rather than by *pointer *But the same conditions as above apply to data | members |
| one may need a pointer because the data members is *optional or because only the type of a *base class *is | known |
| pass ownership into called function auto_ptr< T > sole copy transfer | Deprecated |
| pass ownership into called function auto_ptr< T > sole copy transfer but not where shared ownership is inappropriate Inappropriate use can obfuscate correct ownership and contribute to fragile code weak_ptr< T > none shallow Use is subtle When one of these looks | suitable |
| pass ownership into called function auto_ptr< T > sole copy transfer but not where shared ownership is inappropriate Inappropriate use can obfuscate correct ownership and contribute to fragile code weak_ptr< T > none shallow Use is subtle When one of these looks cet::exempt_ptr< T > is probably more appropriate scoped_ptr< T > sole not allowed object created locally in | function |
| data member for class that should not be copyable value_ptr< T > sole deep polymorphic data | member |
| keep pointer to base | class |
| keep pointer to base but do not share the instance you point to with others exempt_ptr< T > none shallow Use as necessary to convey the information that the memory pointed to is *not * | owned |
| keep pointer to base but do not share the instance you point to with others exempt_ptr< T > none shallow Use as necessary to convey the information that the memory pointed to is *not sometimes called the *compiler firewall *or *letter envelope * | technique |
| keep pointer to base but do not share the instance you point to with others exempt_ptr< T > none shallow Use as necessary to convey the information that the memory pointed to is *not sometimes called the *compiler firewall *or *letter envelope can be used to make private members of a class truly invisible See **C Coding Standards by Sutter and | Alexandrescu |
| using documenting. Summary = ====== The following table summarizes the guidelines in this document. In all the below, ``T`` represents the type *pointed to* by the given pointer type. ================= ========= ============== ========================== Pointer type Ownership Move / Copy Example uses ================= ========= ============== ========================== ``T*`` none shallow should be rare, especially as class data ``unique_ptr<T>`` sole move-transfer return newly created object |
Definition at line 353 of file PointerGuidelines.txt.
| The stack based allocation of the object s assures that it will not be leaked The following code is never appropriate:: void bad_f | ( | ) |
Definition at line 217 of file PointerGuidelines.txt.
| The Standard Library | ( | ISO C++ | 2011 | ) |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns prematurely | ( | either by calling``return`` | , |
| or throwing an | exception, | ||
| or by calling something that throws an | exception | ||
| ) |
| The Standard available from<memory> inherited from C (deprecated) * ``std event put | ( | std::move(myProdPtr) | ) |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic:: Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be but also might* not* be made Creation of a pointer to base that will be initialized to point to some derived type Creation of a very large one that would require an unreasonable amount of stack space In such a pointer of some type is appropriate** In none of the cases listed above is a bare pointer appropriate** To choose the correct pointer consider the issues of* ownership* and the intended semantics of* copying* Ask the following then use scoped_ptr This will prevent your pointer from being copied accidentally If it makes sense to copy the should the copied pointer* share control of the pointed to object* If then use shared_ptr | ( | If your object already has an embedded reference | count, |
| then use``intrusive_ptr`` | . | ||
| ) |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic:: Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be but also might* not* be made Creation of a pointer to base that will be initialized to point to some derived type Creation of a very large one that would require an unreasonable amount of stack space In such a pointer of some type is appropriate** In none of the cases listed above is a bare pointer appropriate** To choose the correct pointer consider the issues of* ownership* and the intended semantics of* copying* Ask the following then use scoped_ptr This will prevent your pointer from being copied accidentally If it makes sense to copy the should the copied pointer* share control of the pointed to object* If then use should the act of copying* transfer ownership* to the new pointer If then use auto_ptr This is useful in functions that are to indicate that ownership of the created object that is returned by the call is given to the caller It is useful in functions that are sinks | ( | such as``art::Event::put`` | ) |
| p someMemberFunctionOfTypeX | ( | ) |
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic:: Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be but also might* not* be made Creation of a pointer to base that will be initialized to point to some derived type Creation of a very large one that would require an unreasonable amount of stack space In such a pointer of some type is appropriate** In none of the cases listed above is a bare pointer appropriate** To choose the correct pointer consider the issues of* ownership* and the intended semantics of* copying* Ask the following then use scoped_ptr This will prevent your pointer from being copied accidentally If it makes sense to copy the should the copied pointer* share control of the pointed to object* If then use should the act of copying* transfer ownership* to the new pointer If then use auto_ptr This is useful in functions that are sources | ( | that | is, |
| *factory functions * | |||
| ) |
| in some code it could be surprising or even disastrous for an object to be shared between many owners Try value_ptr | ( | below | ) |
Definition at line 159 of file PointerGuidelines.txt.
| keep pointer to base but do not share the instance you point to with others exempt_ptr<T> none shallow Use as necessary to convey the information that the memory pointed to is* not sometimes called the* compiler firewall* or* letter envelope can be used to make private members of a class truly invisible See** C Coding Standards by Sutter and Alexandrescu |
Definition at line 399 of file PointerGuidelines.txt.
| the unnamed unique_ptr object is immediately which then deletes the pointed to object ownership is transferred by not move semantics The act of copying an auto_ptr empties the original In C |
Definition at line 144 of file PointerGuidelines.txt.
| Appendix that is a string const &watchPrePathBeginRun watchPrePathEndRun watchPrePathBeginLumi watchPrePathEndLumi watchPreProcessPath The following activities have one argument by the time the module specific code is reached In each of these cases |
Definition at line 230 of file PointerGuidelines.txt.
Definition at line 380 of file PointerGuidelines.txt.
| the unnamed unique_ptr object is immediately which then deletes the pointed to object ownership is transferred by copying |
Definition at line 144 of file PointerGuidelines.txt.
Definition at line 144 of file PointerGuidelines.txt.
Definition at line 361 of file PointerGuidelines.txt.
| the word* pointer* should be understood to include* bare pointers* and all sorts of* smart pointers* The most important guideline and mean what you say This means that you should use the pointer type that most directly conveys the purpose of the code Writing your code so that it* clearly expresses your intent* takes little extra effort |
Definition at line 1 of file PointerGuidelines.txt.
| pass ownership into called function auto_ptr<T> sole copy transfer but not where shared ownership is inappropriate Inappropriate use can obfuscate correct ownership and contribute to fragile code weak_ptr<T> none shallow Use is subtle When one of these looks cet::exempt_ptr<T> is probably more appropriate scoped_ptr<T> sole not allowed object created locally in function |
Definition at line 361 of file PointerGuidelines.txt.
| The use this makes sure that code that* calls* this function takes ownership of the newly created object With such an implementation |
Definition at line 142 of file PointerGuidelines.txt.
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic:: Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases include |
Definition at line 230 of file PointerGuidelines.txt.
| the word* pointer* should be understood to include* bare pointers* and all sorts of* smart pointers* The most important guideline and mean what you say This means that you should use the pointer type that most directly conveys the purpose of the code Writing your code so that it* clearly expresses your intent* takes little extra and pays large dividends in the future The lifetime of an experiment is quite long The code you write today is likely to be read and modified by you or by someone else many months or years from now If you use a pointer type that does not express the right intent |
Definition at line 1 of file PointerGuidelines.txt.
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic:: Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that is |
Definition at line 1 of file PointerGuidelines.txt.
| one may need a pointer because the data members is* optional or because only the type of a* base class* is known |
Definition at line 310 of file PointerGuidelines.txt.
| The use this makes sure that code that* calls* this function takes ownership of the newly created object With such an even code that fails to accept the newly created object does not cause a memory leak |
Definition at line 142 of file PointerGuidelines.txt.
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic:: Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be made |
Definition at line 230 of file PointerGuidelines.txt.
Definition at line 376 of file PointerGuidelines.txt.
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic:: Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be but also might* not* be made Creation of a pointer to base that will be initialized to point to some derived type Creation of a very large one that would require an unreasonable amount of stack space In such a pointer of some type is appropriate** In none of the cases listed above is a bare pointer appropriate** To choose the correct pointer consider the issues of* ownership* and the intended semantics of* copying* Ask the following then use scoped_ptr This will prevent your pointer from being copied accidentally If it makes sense to copy the should the copied pointer* share control of the pointed to object* If then use should the act of copying* transfer ownership* to the new pointer If then use auto_ptr This is useful in functions that are to indicate that ownership of the created object that is returned by the call is given to the caller It is useful in functions that are to indicate that the called function is taking control of the passed object If it makes sense to copy the should the copy manage its own copy of the pointed to object If then use value_ptr Copying a value_ptr creates a* deep copy* of the pointed to object topic:: Guideline Use a pointer type only when necessary Choose the type of pointer after considering* object ownership* and* copying semantics* For class data members Please refer to EDM documentation for special issues regarding design of classes used as EDProducts Such classes are subject to restrictions imposed by the art Event Data Model and the persistency system It is very rarely correct to have a class contain a bare pointer as a data member [#] _ This is because a bare pointer does not convey any sense of* ownership* Most data members of a class should be held by* value rather than by* pointer* But the same conditions as above apply to data members |
Definition at line 307 of file PointerGuidelines.txt.
| the ParameterSet object passed in for the configuration of a destination should be the only source that can affect the behavior of that destination This is to eliminate the dependencies of configuring a destination from multiple mostly from the defaults It suppresses possible glitches about changing the configuration file somewhere outside of a destination segament might still affect the behavior of that destination In the previous configuration for a specific the value of a certain e may come from following and have been suppressed It the configuring ParameterSet object for each destination will be required to carry a parameter list as complete as possible If a parameter still cannot be found in the ParameterSet the configuration code will go look for a hardwired default directly The model is a great simplicity comparing with the previous especially when looking for default values Another great advantage is most of the parameters now have very limited places that allows to appear Usually they can only appear at one certain level in a configuration file For in the old configuring model or in a default ParameterSet object inside of a or in a category or in a severity object This layout of multiple sources for a single parameter brings great confusion in both writing a configuration and in processing the configuration file Under the new the only allowed place for the parameter limit to appear is inside of a category which is inside of a destination object Other improvements simplify the meaning of a destination name In the old a destination name has multiple folds of meanings the e cout and cerr have the special meaning of logging messages to standard output or standard error the name also serves as the output filename if the destination is a file these names are also references to look up for detailed configurations in configuring the MessageFacility The multi purpose of the destination name might cause some unwanted behavior in either writing or parsing the configuration file To amend in the new model the destination name is now merely a name for a which might represent the literal purpose of this or just an id All other meanings of the destinations names now go into the destination ParameterSet as individual such as the type parameter and filename parameter Following is the deatiled rule for the new configuring Everything that is related with MessageFacility configuration must be wrapped in a single ParameterSet object with the name MessageFacility The MessageFacility ParameterSet object contains a series of top level parameters These parameters can be chosen a vector of string listing the name of debug enabled models Or use *to enable debug messages in all modules a vector of string a vector of string a vector of string a ParameterSet object containing the list of all destinations The destinations ParameterSet object is a combination of ParameterSet objects for individual destinations There are two types of destinations that you can insert in the destinations ParameterSet object |
Definition at line 230 of file PointerGuidelines.txt.
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic:: Guideline Prefer to put local objects on the stack Less often |
Definition at line 230 of file PointerGuidelines.txt.
| keep pointer to base but do not share the instance you point to with others exempt_ptr<T> none shallow Use as necessary to convey the information that the memory pointed to is* not* owned |
Definition at line 386 of file PointerGuidelines.txt.
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic::Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be but also might *not *be made Creation of a pointer to base that will be initialized to point to some derived type Creation of a very large one that would require an unreasonable amount of stack space In such a pointer of some type is appropriate **In none of the cases listed above is a bare pointer appropriate **To choose the correct pointer consider the issues of *ownership *and the intended semantics of *copying *Ask the following then use scoped_ptr This will prevent your pointer from being copied accidentally If it makes sense to copy the should the copied pointer *share control of the pointed to object *If then use should the act of copying *transfer ownership *to the new pointer If then use auto_ptr This is useful in functions that are to indicate that ownership of the created object that is returned by the call is given to the caller It is useful in functions that are to indicate that the called function is taking control of the passed object If it makes sense to copy the pointer |
Definition at line 230 of file PointerGuidelines.txt.
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return prematurely |
Definition at line 230 of file PointerGuidelines.txt.
| the word* pointer* should be understood to include* bare pointers* and all sorts of* smart pointers* The most important guideline and mean what you say This means that you should use the pointer type that most directly conveys the purpose of the code Writing your code so that it* clearly expresses your intent* takes little extra and pays large dividends in the future The lifetime of an experiment is quite long The code you write today is likely to be read and modified by you or by someone else many months or years from now If you use a pointer type that does not express the right that later reader is likely to mistake the purpose |
Definition at line 1 of file PointerGuidelines.txt.
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic:: Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be but also might* not* be made Creation of a pointer to base that will be initialized to point to some derived type Creation of a very large one that would require an unreasonable amount of stack space In such a pointer of some type is appropriate** In none of the cases listed above is a bare pointer appropriate** To choose the correct pointer consider the issues of* ownership* and the intended semantics of* copying* Ask the following questions |
Definition at line 230 of file PointerGuidelines.txt.
Definition at line 223 of file PointerGuidelines.txt.
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic::Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be but also might *not *be made Creation of a pointer to base that will be initialized to point to some derived type Creation of a very large one that would require an unreasonable amount of stack space In such a pointer of some type is appropriate **In none of the cases listed above is a bare pointer appropriate **To choose the correct pointer consider the issues of *ownership *and the intended semantics of *copying *Ask the following then use scoped_ptr This will prevent your pointer from being copied accidentally If it makes sense to copy the should the copied pointer *share control of the pointed to object *If then use should the act of copying *transfer ownership *to the new pointer If then use auto_ptr This is useful in functions that are to indicate that ownership of the created object that is returned by the call is given to the caller It is useful in functions that are to indicate that the called function is taking control of the passed object If it makes sense to copy the should the copy manage its own copy of the pointed to object If so |
Definition at line 230 of file PointerGuidelines.txt.
| pass ownership into called function auto_ptr<T> sole copy transfer but not where shared ownership is inappropriate Inappropriate use can obfuscate correct ownership and contribute to fragile code weak_ptr<T> none shallow Use is subtle When one of these looks suitable |
Definition at line 361 of file PointerGuidelines.txt.
| keep pointer to base but do not share the instance you point to with others exempt_ptr<T> none shallow Use as necessary to convey the information that the memory pointed to is* not sometimes called the* compiler firewall* or* letter envelope* technique |
Definition at line 386 of file PointerGuidelines.txt.
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly because it is fragile Changes made at a later date may invalidate the statement that the code can not return and every modification to this code must be checked carefully to make sure that the object pointed to by s can not be leaked topic:: Guideline Prefer to put local objects on the stack Less heap based allocation is needed Some of these cases that an object that might be but also might* not* be made Creation of a pointer to base that will be initialized to point to some derived type Creation of a very large one that would require an unreasonable amount of stack space In such a pointer of some type is appropriate** In none of the cases listed above is a bare pointer appropriate** To choose the correct pointer type |
Definition at line 230 of file PointerGuidelines.txt.
| the word* pointer* should be understood to include* bare pointers* and all sorts of* smart pointers* The most important guideline and mean what you say This means that you should use the pointer type that most directly conveys the purpose of the code Writing your code so that it* clearly expresses your intent* takes little extra and pays large dividends in the future The lifetime of an experiment is quite long The code you write today is likely to be read and modified by you or by someone else many months or years from now If you use a pointer type that does not express the right that later reader is likely to mistake the and modify your code incorrectly The resulting coding errors are often very difficult to debug A small amount of effort used to select the right type can prevent such troubles This is explained in more detail below Pointer Types |
Definition at line 53 of file PointerGuidelines.txt.
| Even though this code calls delete on it is still poorly written If the code represented by the ellipsis returns it is still poorly written |
Definition at line 230 of file PointerGuidelines.txt.
| X* xptr = p.operator->() |
Definition at line 65 of file PointerGuidelines.txt.
| the word* pointer* should be understood to include* bare pointers* and all sorts of* smart pointers* The most important guideline and mean what you say This means that you should use the pointer type that most directly conveys the purpose of the code Writing your code so that it* clearly expresses your intent* takes little extra and pays large dividends in the future The lifetime of an experiment is quite long The code you write today is likely to be read and modified by you or by someone else many months or years from now If you use a pointer type that does not express the right that later reader is likely to mistake the and modify your code incorrectly The resulting coding errors are often very difficult to debug A small amount of effort used to select the right type can prevent such troubles This is explained in more detail below Pointer so that instances can be created to point to objects of various types Smart pointer types differ in their behavior All support* dereferencing* and* member selection* The code below shows the common (but not universal) interface X& xref = *p |
Definition at line 64 of file PointerGuidelines.txt.
1.8.11
