Typedefs | Functions | Variables
canvas/doc/PointerGuidelines.txt File Reference

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
 

Typedef Documentation

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.

Function Documentation

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.

217  {
218  SomeType* s = new SomeType(...); // create it on the heap
219  ... use the object pointed to by s ...
220  delete s;
221  }
s
Even though this code calls delete on s
Definition: PointerGuidelines.txt:223
by
HOW TO RUN THIS CODE by
Definition: samweb_commands.txt:14
the
another_number the
Definition: to_indented_string_annotated_test-ref.txt:6
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.

162  :
163  ``weak_ptr`` is provided to give *shared access* with *no ownership*
164  to an object which is managed through a ``shared_ptr``.
165  Its correct use is fairly subtle,
166  and it should rarely be needed. It is chiefly used to break cyclic
167  references to objects.
168 
169 ``boost::scoped_ptr<T>``:
170  ``scoped_ptr`` implements *sole ownership*, with the restriction that
171  the ``scoped_ptr`` object itself *can not be copied*.
172  If you want a pointer that is to be the only owner for some other object,
173  and makes sure that the pointer is not copied,
174  so that no other pointer refers to the same object *and*
175  your pointer never gives up its object to control by another object,
176  then ``scoped_ptr`` is the correct choice.
177 
178 ``boost::intrusive_ptr<T>``:
179  ``intrusive_ptr`` is very similar to ``shared_ptr``. They differ in
180  that ``intrusive_ptr`` can only be used to point to an object with
181  an embedded reference count. Its use will be rare.
182  Quoting from the ``intrusive_ptr`` documentation: "As a general rule,
183  if it isn't obvious whether ``intrusive_ptr`` better fits your needs
184  than ``shared_ptr``, try a ``shared_ptr``-based design first."
185 
186 ``cet::value_ptr<T>``:
187  ``value_ptr`` implements *sole ownership*. Copying a ``value_ptr``
188  causes a copy of the pointed-to object to be created. This makes
189  ``value_ptr`` useful for managing class data members when the
190  shared ownership of ``shared_ptr`` is inappropriate.
191 
192 ``cet::exempt_ptr<T>``:
193  ``exempt_ptr`` *explicitly does not own* the memory associated with
194  its conained pointer. Use in preference to a bare pointer to make it
195  clear that the receiver of an ``exempt_ptr`` does not own its
196  pointed-to object.
197 
198 Usage Guidelines
199 ================
200 
201 For local use in functions
202 --------------------------
203 
204 Most often, objects which are local to functions
205 should not be ``new``'d.
206 Thus, no pointer is needed::
207 
208  void f() {
209  SomeType s; // create it on the stack
210  ... use the object s ...
211  } // s destroyed on function exit
created
and must be present Because it has no parameters to and because it is always created
Definition: CONFIGURATION_NOTES.txt:1
fhicl::has_insertion_operator_impl::no
char no
Definition: TupleAs.h:156
are
these are all by getting the vString this is set to true if debugModules is non empty everyDebugEnabled_ is a global scope variable instantiated as false in MessageLogger cc In the ctor of this is set to true if nay one of debugModules is *debugEnabledModules_ contains the specified debugModules If debugEnabled is set to then the effect of LogDebug used during that module is to immediately return A subtlety arose concerning the MessageDrop in circumstances where the framework s event processing structure were not in play In if preModule were never then debugEnabled would remain whatever value it had on construction of the MessageDrop the value was left uninitialized Now it is initialized to true in the ctor for we change debugEnabled MessageDrop s debugEnabled to false Configuring Destinations The each destination has its own tables of what to do about each category and but we get various overall defaults fromm the cfg file as well The limit instructions at the MessageLogger level takes on forms in order of priority of these are
Definition: Design_and_maintenance.txt:216
objects
var objects
Definition: slidy.js:101
s
Even though this code calls delete on s
Definition: PointerGuidelines.txt:223
cet::value_ptr< T >
members
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: PointerGuidelines.txt:307
bump_copyright.d
string d
Definition: bump_copyright.py:70
count
Int_t count[12]
Definition: f2_nu.C:140
is
the word *pointer *should be understood to include *bare pointers *and all sorts of *smart pointers *The most important guideline is
Definition: PointerGuidelines.txt:1
up
*externals *admin sets up
Definition: meeting-2009.02.03.txt:27
used
services supplied by experiments are configured by parameters in the contained table named *user *The suggested type for those parameters is *table which is beyond the scope of this document Names in the *source an *EmptySource *configured to deliver one event is constructed If a *source *table is the only parameter required names the type of source to be used
Definition: PARAMETERS.txt:126
f
FILE * f
Definition: loadlibs.C:26
not
The private default constructor with no arguments first calls then sets stmt_ to the and then default initializes the registry_ data member it would be better to initialize primaryDB_ to and then calls or on error it does not
Definition: fhiclcpp_threading_notes_supporting_details.txt:581
shared_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 shared_ptr(If your object already has an embedded reference count, then use``intrusive_ptr``.) 3.If it makes sense to copy the pointer
of
another_number of
Definition: to_indented_string_annotated_test-ref.txt:6
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 often
Definition: PointerGuidelines.txt:230
correct
const char * correct[]
Definition: Exception_t.cc:113
a
const double a
Definition: gUpMuFluxGen.cxx:164
it
How the MessageService Sets Up the Module Name This document describes how the module and any suppression gets where the logger needs it
Definition: moduleTracking.txt:4
does
Actions and Circumstances Relevant to Incomplete Log Problem The some of the LogInfo messages issued at the end involving branch information are failing to emerge This necessitates re running the for a net loss of up to of the work done The problem can t be happening based on what the logger does
Definition: flush-and-end.txt:9
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 object
Definition: PointerGuidelines.txt:230
point
the code is simple for extract with default of NO_VALUE_SET At this point
Definition: Design_and_maintenance.txt:312
by
HOW TO RUN THIS CODE by
Definition: samweb_commands.txt:14
from
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 from
Definition: MessageFacilityAsStandAlonePackage.txt:82
that
the code is simple for that
Definition: Design_and_maintenance.txt:312
the
another_number the
Definition: to_indented_string_annotated_test-ref.txt:6
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 so
Definition: PointerGuidelines.txt:230
art::InputSourceFactory::make
unique_ptr< InputSource > make(ParameterSet const &conf, InputSourceDescription &desc)
Definition: InputSourceFactory.cc:23
reference
mu2e meeting What is working services read write root files initial runtime initial build with some But rather a stl prepocessor directive _GLIBCXX_DEBUG_ What is not working high level instruction for use web page external products in AFS including histogram Run needed documentation classes that are scheduling issue product to product reference(class) hits(product)
value_ptr
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
Definition: PointerGuidelines.txt:159
in
This add method has three it adds this message xid and id to the appropriate and it updates the dynamic information in counts The sequence is as the static apppropriate and timespan will be in the mapped CountAndLimit and there will be no need to recompute them If this xid is not yet in see if the category is in limits if the appropriate counts struct can be formed by using the precedence rules above to combine the limit and interval found in limits along with the severityLimits and severityIntervals arrays found in the ELlimitsTable Along the way the limits map for this category is filled in
Definition: Design_and_maintenance.txt:460
provided
Making New Hardwired Defaults for the and how to create a specialized set of selectable by doing mute mode whateverNameYouChoose The MessageLogger has a set of hardwired for use when no MessageLogger configuration appears in the config file These match the contents of the MessageLogger cfi file Although these defaults are hardwired into it is recognized that changing circumstances and experience withthe framework will make necessary changes in the defaults the defaults are kept in a clean form in one for ease of modification Multiple sets of these defaults can be provided
Definition: MakingNewDefaults.txt:5
new
TAG v03_09_00 Replaced parent algorithms with new master which uses Pandora worker rather than purely daughter algorithms and tools Plugins now handle presence of multiple LArTPCs registered with master instance Slicing now occurs entirely within a Pandora worker instance Introduced pre and post processing algorithms Added LArControlFlow collecting tools and other content associated with overall control flow Added new
Definition: ChangeLog.txt:4
functions
See appendix A for details of module types other than EDAnalyzer EDAnalyzer has the virtual following void functions
Definition: moduleTracking.txt:51
copy
T copy(T const &v)
Definition: RangeForWrapper_test.cc:127
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 pointer
Definition: PointerGuidelines.txt:230

Variable Documentation

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.

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

Definition at line 230 of file PointerGuidelines.txt.

keep pointer to base class

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.

the unnamed unique_ptr object is immediately deleted

Definition at line 144 of file PointerGuidelines.txt.

pass ownership into called function auto_ptr<T> sole copy transfer Deprecated

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.

data member for class that should not be copyable value_ptr<T> sole deep polymorphic data member

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.

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

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
Initial value:
================= ========= ============== ========================================
----
.. _boost: http:
.. [#] An obvious exception is in smart pointer class templates themselves.
.. [#] The *pimpl* technique
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 * technique
Definition: PointerGuidelines.txt:386
http
**********************************************************************************************************************************************************************************************************************oooooo oooooooooooo ooooo ooo ooooo oooooooooooo ****d8P Y8b NEUTRINO MONTE CARLO GENERATOR ********Version ****ooooo ****o o http
Definition: genie_banner_long.txt:13
is
the word *pointer *should be understood to include *bare pointers *and all sorts of *smart pointers *The most important guideline is
Definition: PointerGuidelines.txt:1
in
This add method has three it adds this message xid and id to the appropriate and it updates the dynamic information in counts The sequence is as the static apppropriate and timespan will be in the mapped CountAndLimit and there will be no need to recompute them If this xid is not yet in see if the category is in limits if the appropriate counts struct can be formed by using the precedence rules above to combine the limit and interval found in limits along with the severityLimits and severityIntervals arrays found in the ELlimitsTable Along the way the limits map for this category is filled in
Definition: Design_and_maintenance.txt:460
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 pointer
Definition: PointerGuidelines.txt:230
fhicl::exception
cet::coded_exception< error, detail::translate > exception
Definition: exception.h:33

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.

Even though this code calls delete on s

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
Initial value:
=============
Smart pointer types are usually written as *class templates*
are
these are all by getting the vString this is set to true if debugModules is non empty everyDebugEnabled_ is a global scope variable instantiated as false in MessageLogger cc In the ctor of this is set to true if nay one of debugModules is *debugEnabledModules_ contains the specified debugModules If debugEnabled is set to then the effect of LogDebug used during that module is to immediately return A subtlety arose concerning the MessageDrop in circumstances where the framework s event processing structure were not in play In if preModule were never then debugEnabled would remain whatever value it had on construction of the MessageDrop the value was left uninitialized Now it is initialized to true in the ctor for we change debugEnabled MessageDrop s debugEnabled to false Configuring Destinations The each destination has its own tables of what to do about each category and but we get various overall defaults fromm the cfg file as well The limit instructions at the MessageLogger level takes on forms in order of priority of these are
Definition: Design_and_maintenance.txt:216
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 written
Definition: PointerGuidelines.txt:230
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 pointer
Definition: PointerGuidelines.txt:230

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.

Generated by   doxygen 1.8.11