Retool TriggerGenericMaker to behave differently for Set<T> input/output #34
Conversation
Introduces a helper class Worker to deal with the partial specialization of the do_work method. This allows Set<A> -> OUT and Set<A> -> Set<B> to be handled correctly
There was a problem hiding this comment.
There's quite a bit of nearly-the-same code here, which makes me wonder if it's worth rethinking the lack of a TCSet. If we had a TCSet, then you wouldn't need the Worker<Set<A>, OUT, MAKER> specialization (is that correct?). We could then either modify the downstream code to accept TCSets or we could add some small bit of code that takes the TCSets and "explodes" them into their component TCs for consumers. Would that be an overall improvement?
|
That's right, if everything were a I did shuffle some code around to reduce how much redundant parts there were in the (renamed) |
|
Yes, that looks better, and shows how we can factor out common parts between the specializations. Thanks. A couple more individual-line comments coming... |
| // some fraction of the times that we check, so we just continue on and try again | ||
| continue; | ||
| m_parent.m_maker->operator()(in, out_vec); | ||
| } catch (...) { // TODO BJL May 28-2021 can we restrict the possible exceptions triggeralgs might raise? |
There was a problem hiding this comment.
Good idea. I've opened an issue in triggeralgs for tracking/discussion: DUNE-DAQ/triggeralgs#12
Logic here assumes that all Set<T> in a time slice have the same start_time and end_time and come in on the queues in time order. All objects of the Set<T> in the time slice are then sorted by time_start before being passed to the operator() of algorithms.
Introduces a helper class
TriggerGenericWorkerto deal with the partial specialization of thedo_workmethod. This allows queues of typeSet<A>->OUTandSet<A>->Set<B>to be handled correctly. Unfortunately C++ does not yet allow partial specialization of methods in a template class, and the helper class is the cleanest workaround for this.