KAHIBARO
3.3. Pointers and References
Table of Contents
C++ pointers
In Geant4 applications you will see raw C++ pointers everywhere, for example in class members, factory functions, and ownership-transferring interfaces. Understanding what a pointer is and how to read pointer syntax is essential before you can follow typical Geant4 code.
A pointer is a variable that stores a memory address. Instead of holding an integer or a double value, it holds the location of some other object in memory. You declare a pointer by adding a to the type. For example, G4Track is a pointer to a G4Track object, and G4VPhysicalVolume* is a pointer to a G4VPhysicalVolume.
Two operators are central to pointer use. The address-of operator & produces a pointer from an object, for example G4double p = &myValue;. The dereference operator follows a pointer to access the object at that address, for example p = 1.0;. For class types, you use the arrow operator -> as shorthand for dereferencing followed by member access. Instead of (track).GetTrackID(), you write track->GetTrackID().
Geant4 interfaces usually accept and return pointers to base classes. For instance, your detector construction must return a G4VPhysicalVolume* from Construct(), and the run manager stores that pointer internally. A simplified example is:
G4VPhysicalVolume* MyDetectorConstruction::Construct() {
// build world volume and return its pointer
return fWorldPhys; // fWorldPhys is a G4VPhysicalVolume*
}In this call, only the address is passed, not a copy of the volume. This is why multiple parts of the program can refer to the same geometry or track object at the same time.
You must distinguish between a pointer variable and the object it points to. If you have G4LogicalVolume* logicDetector;, then logicDetector is just an address. The actual volume object lives somewhere else in memory. If logicDetector is uninitialized, it does not point to a valid object, and calling logicDetector->SetMaterial(...) will cause undefined behavior and can crash your program.
Always make sure a pointer is valid before you use it. Do not dereference null or uninitialized pointers. A null pointer is conventionally represented by nullptr. Accessing nullptr->member is an error.
In modern C++ you can and should prefer smart pointers where possible, but the Geant4 API is based on raw pointers, so you must be comfortable with reading and writing code that uses them. For this course we focus on understanding the semantics and lifetime issues that occur when you pass pointers around in Geant4 classes and callbacks.
References
A reference in C++ is an alias to an existing object. Once bound, a reference refers to the same object for its entire lifetime and cannot be reseated. You declare a reference with & in the type, for example
G4Step& step = *aStepPtr;
Here step is a reference to a G4Step object, not a pointer. You access members with the normal dot operator .. If aStepPtr points to a valid G4Step, then step.GetTotalEnergyDeposit() and aStepPtr->GetTotalEnergyDeposit() produce the same result.
References are widely used in Geant4 interfaces to avoid copying large objects and to emphasize that a function expects a valid object. A typical example is a method that takes a const G4Step* pointer from the framework, and then internally creates a reference for convenience:
void MySteppingAction::UserSteppingAction(const G4Step* stepPtr) {
const G4Step& step = *stepPtr;
G4double edep = step.GetTotalEnergyDeposit();
// use edep ...
}
The pointer stepPtr can be null in some interfaces, so you must check that before dereferencing. The reference step itself is assumed valid. Once you have a reference, you cannot later make it refer to some other step, which makes reasoning about the code easier.
Because references cannot be null, they are often safer than pointers for function parameters when you know the caller will always pass a valid object. For example, if your helper function always processes an existing G4ThreeVector, you might declare:
void PrintPosition(const G4ThreeVector& pos);
This communicates that PrintPosition does not take ownership of pos, will not modify it, and expects it to exist for the duration of the call.
A reference does not extend the lifetime of the object it refers to. Never store a reference to a temporary object or to an object that will go out of scope while the reference is still used. Using such a dangling reference is undefined behavior.
In summary, pointers and references are both ways to access existing objects without copying them. Geant4 generally uses pointers for ownership and framework callbacks, and references for convenience and to indicate non-null parameters inside your own code.
Dynamic objects
Dynamic objects are objects that you create manually on the heap with new. Heap allocation gives you precise control over an object's lifetime and lets you build complex structures such as trees and graphs. Geant4 historically uses dynamic allocation for many of its core objects, and you will often allocate your own classes in the same way.
The basic pattern is:
MyClass* obj = new MyClass(arguments);
// use obj
delete obj;
obj = nullptr;
Here new MyClass(...) creates the object, and delete obj; destroys it and releases its memory. This pattern is very common for user initialization classes and geometry objects. For example, your main() function might do:
auto* runManager = new G4RunManager;
runManager->SetUserInitialization(new MyDetectorConstruction);
runManager->SetUserInitialization(new MyPhysicsList);
runManager->SetUserInitialization(new MyActionInitialization);
// run simulation
delete runManager;
The run manager takes ownership of the initialization classes you pass with new. It deletes them when it is itself deleted. You must understand this ownership rule so that you do not delete the same object twice or forget to delete something that you own.
Many Geant4 factory methods also return pointers to dynamically allocated objects that Geant4 will manage. For example, when you create solids, logical volumes, and physical volumes, you typically write:
auto* solidWorld =
new G4Box("World", 0.5*m, 0.5*m, 0.5*m);
auto* logicWorld =
new G4LogicalVolume(solidWorld, worldMaterial, "World");
auto* physWorld =
new G4PVPlacement(
nullptr,
G4ThreeVector(),
logicWorld,
"World",
nullptr,
false,
0,
true);
You never call delete on these geometry objects in a simple application. The Geant4 geometry manager owns them and will clean them up when the run manager is destroyed or when you explicitly clean the geometry. This illustrates an important rule for working with dynamic objects in Geant4.
Always respect ownership conventions. If Geant4 takes ownership of a pointer, do not delete it yourself. If you create an object with new and keep the pointer only in your own class, you are responsible for deleting it in your destructor.
For your own helper objects that are not handed to Geant4, such as small analysis managers or configuration holders, you can choose between dynamic allocation and automatic (stack) allocation. In modern C++ it is often simpler and safer to avoid new altogether and use automatic storage duration:
MyAnalysis analysis; // automatic object, no delete needed
However, there are many Geant4 interfaces where you must still create objects dynamically. As you work through this course, pay attention to where new appears and look for comments or documentation that explain who owns the created object and when it will be destroyed.
When an object owns other dynamically allocated objects, it should clean them up in its destructor. This pattern is used inside Geant4 and is also useful in your own classes:
class MyManager {
public:
MyManager()
: fHelper(new MyHelper) {}
~MyManager() {
delete fHelper;
}
private:
MyHelper* fHelper;
};
Here the MyManager object manages the lifetime of fHelper. Whenever you design such classes, think in terms of clear ownership and single responsibility for deletion. This prevents memory leaks and double deletions, both of which can be serious problems in long Geant4 runs.
Dynamic objects, pointers, and references together form the foundation for how Geant4 manages its complex simulation state. With these concepts in place, you will be able to understand how user classes are created, how they interact, and how the framework controls their lifetime.
Views: 10