Monitoring data is included in cbm::algo::EventBuilder.
In keeping with the style of other algorithms, a struct with monitoring data is introduced, and a special "resultType" is introduced which combines the regular output with the monitoring information.
Accordingly, GTestEventBuilder was modified to extend the test coverage to the monitoring data. In passing the TRD support for this test was fixed.
Overall, I'm not super happy with the aesthetics of this code. The added blocks of the form
monitor.fSts.fNum += ts.fData.fSts.fDigis.size();
monitor.fRich.fNum += ts.fData.fRich.fDigis.size();
monitor.fMuch.fNum += ts.fData.fMuch.fDigis.size();
...seem a bit cluttery. The only solution that comes to my mind however, would be to use a std::map<ECbmModuleId,EventBuilderDetectorMonitorData> inside the monitor struct. I guess this is not an option, due to the requirement of the monitoring data to be light-weight.
Another issue is that, in places where one only wants to access the constructed events, but not the monitoring data, the most compact expression is something like
*fEvents = fAlgo(*fTimeslice, *fTriggers).first;which is a bit contrived.
I chose to put the monitoring incrementation outside of the switch(ECbmModuleId) statement, again for aesthetic reasons. This can in principle lead to some unnecessary "increment by zero" operations. These will be negligible against "CopyRange()" however, and might even be optimized away by the compiler.
What is nice, is that the output could immediately be verified, by using the existing GTest.