There are predefined classes to handle subevents:
SelectedData<T> name; |
defines name to be a variable
linked to an existing subevent (as select in the hoc language). |
AccessedData<T> name; |
like access in the hoc language |
GeneratedData<T> name; |
name identifies a subevent to
be added to the current containerevent. |
where T is a storage type. Supported storage types are listed in table
The most important member functions of your callback will be the
virtual functions init(), analyze(), and - if desired
- finish().
The function
accept() is called by YODA (by the eventstream object) once for
each containerevent. Via the member functions of Eventstream,
the callback has full access to the containerevent's data. It can then
decide, whether to accept (hence the name) the event for processing
-- it will return a 1 (one) -- or to ignore this containerevent. It
may also pick out one or more pointers to subevents to deal with later
on.
If this function returns one, the member function analyze()
will be called. Here the actual (complicated) analysis should take
place. By using Eventstream member functions, all information
about and inside the current containerevent can be queried. Moreover,
subevents can be deleted and new subevents (containing results of the
analysis) can be generated and added to the current containerevent.
With the optional member function finish(), results can be
printed or saved whenever the data analysis is stopped (either by
end-of-file or by user interaction).
As you may have noticed, the member functions analyze() and
finish() correspond exactly to the hoc-procedures with the same
name. The accept() member function, however, is hidden in the
context of the hoc language and works according to the select
statements given in the hoc procedure init().
After building your hard callback class, you must create a single
object of this class (instantiate it), and ''announce'' this callback
to YODA's eventstream object. This is done in user.cc
with the call eventstream's member function link().