• Print
• View
• History
• Login

Pointers in ROOT, GEANT4 and other disgraced frameworks

Trail Index | References and Pointers | Pointers in Root and Geant4

Root

in ROOT, you are usually forced to use pointers when you construct ROOT object, even when it would not make any sense at all.

This is because ROOT objects are usually registered with some kind of non-standard internal memory handler, a concept which is the unfortunate legacy of the origins of ROOT in the Fortran77 code of CERNLIB/PAW.

So, if you try to delete, for example, a histogram (TH1F), ROOT will not remove its internal record of it, and will, at some random later time, happily crash trying to access the now deallocated memory.

This is against all rules of good OO programming, and against common sense as well. But you will have to live with it.

ROOT developers try to justify this by the convenience provided by the "global dictionary" of all objects that is maintained in this way; but it's no excuse. When something like that is used, the objects should not be allowed a new() operation, and a Factory Pattern be used instead; furthermore, their delete operator should request to the Factory to take care of the appropriate house-cleaning, deleting all references to the object that is being deleted.

Geant4

In all fairness, GEANT4 suffers from the same kind of problems. For example, objects are allocated in the DetectorConstruction, and must not be deleted by the user, since they are implicitly registered in the Geometry, which will delete them when "cleared".

This is exceedingly confusing for the newbies, who have just been told that all allocated memory must be accounted for, and deallocated! They will randomly be punished with incomprehensible segfaults for deallocating objects which they have allocated, and, in a typical Pavlovian reaction, will just stop trying to do it even when they should.

This inconsistency could be easily resolved by changing those

into

allowing the user to clearly distinguish between objects managed by GEANT and those that she actually has to manage on his own (like an Analysis object).

The present status promotes the sloppiness and bad style which are already all too common amongst physicists, who are not well trained in Computer Science.

< Dynamic Memory | Trail Index | Objects 2 >