Message: Unnecessarily restrictive definition of the G4VUserPhysicsList class... Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

Feedback Unnecessarily restrictive definition of the G4VUserPhysicsList class... 

Keywords: G4VUserPhysicsList G4VModularPhysicsList polymorphism
Forum: User Requirements
Date: 26 Oct, 2004
From: Robert Weller <Robert Weller>

This message concerns the definition of the abstract base class G4VUserPhysicsList. This class contains two pure virtual functions, ConstructProcess() and ConstructParticle() that must be defined in derived classes such as Hans-Peter Wellisch's use-case physics lists and custom user physics lists such as those in the examples. In the abstract base class, they are declared as protected, although in derived classes, except G4VModularPhysicsList, which itself is used as an abstract base class, they are always public. Here is the problem. By making these protected, an important form of polymorphism is unnecessarily disallowed, since the Construct() function cannot access them from a generic G4VModularPhysicsList pointer.

"So what?", you may say. Well, first it's poor object-oriented programming design to place unnecessary limits on polymorphism. Polymorphism is one of the main reasons for having c++, and it's short-sighted to restricte it without just cause. In this case, it should be trivial to write a very simply user physics list that makes it possible to pick between any number of concrete physics lists at run time, using one member function and a messenger. Of course there are other ways to program this, but creating a pointer e.g. "theRealList" of type G4VModularPhysicsList in the user physics list class "myPhysicsList" and defining e.g. void myPhysicsList::ConstructProcess() {theRealList->ConstructProcess();} and similarly for the other function, ConstructParticle(), is an especially simple and elegant approach that the over-zealous applicated of "protected" in G4VModularPhysicsList makes impossible.

In my library that "protected" is now commented out. If someone has a good reason for it being there, I'd appreciate knowing what it is. Otherwise, I strongly suggest that it disappear in the next public release of Geant4, in the interest of good OOP design and user flexibility.

Inline Depth:
 1 1
 All All
Outline Depth:
 1 1
 3 3
 All All
Add message: (add)

1 None: Re: Unnecessarily restrictive definition of the G4VUserPhysicsList class...   (Hisaya Kurashige - 28 Nov, 2004)
 Add Message Add Message
to: "Unnecessarily restrictive definition of the G4VUserPhysicsList class..."

 Subscribe Subscribe

This site runs SLAC HyperNews version 1.11-slac-98, derived from the original HyperNews


[ Geant 4 Home | Geant 4 HyperNews | Search | Request New Forum | Feedback ]