Open jacg opened 1 year ago
So far, the run manager seems to be the only thing the user owns. Everything else in G4 seems to follow the model "Create a new
one and drop it on the floor, G4 will store it in some G4 store" (has a poetic ring to it).
Let's keep our eye out for a little longer, but I suspect there is not much we can do here.
Modern (since C++11) practice dictates that
std::{unique,shared}_ptr
,new
anddelete
should not be seen anywhere in client code (thoughnew
is allowed as an argument to something that takes ownership immediately).In more detail
std::unique_ptr
unique_ptr
means that you are transferring ownership to the receivershared_ptr
means that you are sharing ownership with the receiverThings like
G4PVPlacement
(consequentlyn4::place
), the subclasses ofG4VSolid
,G4LogicalVolume
(thusn4::volume
) all implicitly give ownership to some G4 manager in their constructors. So it is correct that then4
utilities that wrap them, return bare pointers: you can look at this and use it but do not delete it, because it's not yours. So this seems to be consistent with modern C++.G4RunManagerFactory
unfortunately returns a bare pointer, and most users are unaware of it, and construct the run manager directly; in both cases, they end up having to remember todelete
the manager by hand at the end. We already haven4::run_manager
which mitigates this problem.We need to hunt down these sorts of situations and