Modern C++ resource ownership and lifetime management

[jacg]

Modern (since C++11) practice dictates that

• lifetime management should be made explicit through the use of smart pointers, such as std::{unique,shared}_ptr,
• new and delete should not be seen anywhere in client code (though new is allowed as an argument to something that takes ownership immediately).

In more detail

• factories should not return bare pointers, but std::unique_ptr
• passing/returning a bare pointer means that you are letting someone observe a resource without getting involved in its lifetime management
• passing/returning an unique_ptr means that you are transferring ownership to the receiver
• passing/returning a shared_ptr means that you are sharing ownership with the receiver

Things like G4PVPlacement (consequently n4::place), the subclasses of G4VSolid, G4LogicalVolume (thus n4::volume) all implicitly give ownership to some G4 manager in their constructors. So it is correct that the n4 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 to delete the manager by hand at the end. We already have n4::run_manager which mitigates this problem.

We need to hunt down these sorts of situations and

• document (in one place, with a list) which G4 components arg guilty of returning owning bare pointers
• provide abstractions for them in order to reduce the likelyhood of owning bare pointers appearing in user code

[jacg]

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.