New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New TrackingRecHitRange and use it in RecoParticleFlow #25591
Conversation
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-25591/7835 |
A new Pull Request was created by @guitargeek (Jonas Rembser) for master. It involves the following packages: DataFormats/CSCRecHit @perrotta, @cmsbuild, @slava77 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
The tests are being triggered in jenkins. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After a quick code inspection, I found a couple of indentations to be fixed
Comparison job queued. |
@@ -25,6 +25,18 @@ class TrackExtraBase | |||
using TrajParams = std::vector<LocalTrajectoryParameters>; | |||
using Chi2sFive = std::vector<unsigned char>; | |||
|
|||
/// class which implemebts begin() and end() to enable range-based loop on RecHits | |||
class TrackingRecHitCollectionWindow { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think TrackingRecHitRange
would be a better name (closer to standard naming convention). In which case it would probably be better to be defined in DataFormats/TrackingRecHit
. (we could even consider a new class template that could then be instantiated in DataFormats/TrackingRechit/interface/TrackingRecHitFwd.h
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, that name is shorter and better. So I understand correctly that you'd define the class in DataFormats/TrackingRechit/interface/TrackingRecHitFwd.h
? But where would you put the template? Actually I don't know if that pattern reoccurs in CMSSW and the template is necessary. Thanks for your advice!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I understand correctly that you'd define the class in
DataFormats/TrackingRechit/interface/TrackingRecHitFwd.h
That file is for forward declarations so I wouldn't define the TrackingRecHitRange
class there (unless it would be a template instantiation).
But where would you put the template?
I'm thinking edm::ConstRange<T>
(with T
being the iterator type) in either FWCore/Utilities
or DataFormats/Common
. @Dr15Jones, would you have any input?
Actually I don't know if that pattern reoccurs in CMSSW and the template in necessary.
I don't recall seeing this pattern, but many times in the past I would have wanted to use range-for for iterator pairs obtained with something else that begin()
+end()
pair (which reminds me that I may have introduced some ad-hoc range classes somewhere, but can't remember where). I just believe this pattern would have potential to be used elsewhere as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok! So that means if it wouldn't be a template it belongs in DataFormats/TrackingRechit/interface/TrackingRecHit.h
without the Fwd? Hope I understand this well. Alright, let's see what Chris says.
I just recalled there would maybe be more use-cases for such a template. There is for example not only the *Begin()/*End()
pattern that was seen in the tracks, but sometimes people just created pairs to imitate a range, like here:
https://github.com/cms-sw/cmssw/pull/25591/files#diff-2718c8ec8e06c5b5679d465a9c81b6e8R426
If I'm not mistaken I have seen such things elsewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the location of the file is not so important after all, I just suggested how the edm::ConstRange<T>
could look like.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So that means if it wouldn't be a template it belongs in
DataFormats/TrackingRechit/interface/TrackingRecHit.h
without the Fwd?
Or in a separate header.
I just recalled there would maybe be more use-cases for such a template. There is for example not only the *Begin()/*End() pattern that was seen in the tracks, but sometimes people just created pairs to imitate a range, like here:
Yeah, there are plenty of those. Many (if not all) of those predate C++11 and range-for.
Comparison is ready Comparison Summary:
|
Pull request #25591 was updated. @perrotta, @smuzaffar, @cmsbuild, @Dr15Jones, @slava77 can you please check and sign again. |
+1 |
The tests are being triggered in jenkins. |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @davidlange6, @slava77, @smuzaffar, @fabiocos (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
This PR suggests to add a member function to TrackExtraBase which returns an instance of the new TrackingRecHitRange (template instantiation of new edm::ConstRange) that can be used to express range-based loops over the RecHits associated to a track. I think this would be beneficial for the modernization of reconstruction code, as I show at the example of RecoParticleFlow, where I replaced all occurrences of recHitsBegin and recHitsEnd.
Local matrix tests pass.