Many classes like G4RunManager use a singleton approach which has a major flaw because the copy ctor is neither provided nor is the compiler inhibited from synthesizing one. For example the following code would produce a second instance of G4RunManager: G4RunManager SneakyCopy( *G4RunManager::GetRunManager() ); As soon as SneakyCopy goes out of scope the whole system will go down the drain as all the objects to which the original G4RunManager has any pointers, will be deleted. Proposal: Why not impose the usage of a templated generic singleton implementation which takes care of these problems automatically?
Thank you for making notice this issue now also rather well documented in the literature. Please, notice the following: several classes in Geant4 (included G4RunManager and most of the singletons) have been developed in 1995. At that time, the support of most compilers for templates was very poor or totally non-existent, similarly for what concerns the implementation of the singletons where some compilers could not digest a totally 'privatisation' of constructors. G4RunManager in particular is a rather peculiar kind of singleton, since originally it was not meant to be subclassed, and if you read the class specification you'll see that there's a note/warning concerning the possibility of having multiple istances of it... Your proposal is certainly a viable solution, however special care must be given in backward compatibility of the software, since Geant4 is now used in production by many experiments. A redesign for a modular run-manager is foreseen for the December release, where also some of these topics may be considered.
