Goto:
Class list(annot.)
Class members
File list
File members
Everything
Repository structure
Release notes
BuildFiles
.orcarc Parameters
This set of examples shows how to use COBRA basic components to build Object-Oriented Applications based on Implicit Invokation and Action On-Demand. It is not a tutorial about C++ or OO in general, and a good knowledge of these technologies is a pre-requisite.
The example explicitly shows how to interface a procedural code (freely inspired to Geant4 Run and Event Managers and UserActions) to COBRA
Particularly the code in Procedural is very naive and it can be surely improved. The intent is not to show how to optimize procedural code, nor how to write COBRA application from scratch....
It is a typical procedural manager with call-backs. Freely insprired to Geant4.
Loops over events, generates tracks, processes them, manages secondaries.
At critical moments, it invokes a call-back routine, if provided by the user.
As example of "Mandatory" user-provided routine, a simple Generator (with two concrete implementations; Flat and Gauss) is provided.
All the code is in a single file, it is very linear: It should be quite straightforward for any of you to understand what it does reading it just ones.
The limitation of this approach has been discussed and presented several times. Refer for instance to: VI talk at CHEP`97 or V.I. trasparencies at Desy Seminar of Jannuary 26, 1998
The OO wrapper to the Procedural Manager.
What it does is very simple: for each call-back defines and Event that wraps the arguments of the call. Each time a call-back is made an event is dispatched...
The manager is instantiated, all call-backs installed and all this is hidded from the user....
For user-provided mandatory objects I use a SingletonFactory as coded in GeneratorFactories.cc.
At this moment the selection of the concrete Generator is made using a PackageBuilderUIMatch.
If concrete generators resides in different libraries a simple static instantiation of the corresponding SingletonFactory should suffice: once the library is loaded the corresponding generator will be instantiated and registered...
The real main (in COBRA is CARFApplication)
Initilizes the various registered packages in the various package-classes:
A User Interface to verbosity control: set the filter level of verbose to the value of the configurable "Verbosity".
The use of an external reference is to make its usage as simple as possible...
Users can define their own verbosity object instantiating one with a different name as in ReorderStack
. Exercise for the attentive reader: how does the MasterVerbosity mechanism work?
Contains the user code (what a guess!). User code at this point is very COBRA style: any ORCA user should find it very familiar. It is so trivial that it does not need any special comment...
Contains the main to be able to run more examples using just one library.
The present packaging is of course not optimal. Procedural code is supposed to be in some legacy library, OO wrapper in a central package (together with the main), singletons in their own libraries and the use code scattered wherever more appropriate.
Something to note is how the User code depends only on the Events not on any core manager class.
Procedural, Proc2OO etc can be changed at will (not just the implementation, even their interfaces and the way they communicate internally), the user code does not need to be recompiled or re-linked.
The Events are the only User API of the system, all the rest is hidded. This makes the whole interface very coherent and consistent.
Note how, even if the system is fully managed, the managers are not exposed to the users, and in most of the cases not even to the middle-ware. Managers stay in the back-end, the user (and even the application developer him/herself) has the impression of just instantiating free objects.
This allows to change management structure without affecting application code.
This implementation makes full reuse of COBRA basic classes which are fully transparent to the application developer: no explicit registry to handle, no explicit subscription, no pattern to re-implement: just inheritance and object instantiation.
1.3.3