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
No need for GsfElectronCoreBaseProducer and merging .h and .cc files for EgammaElectronProducers #28746
No need for GsfElectronCoreBaseProducer and merging .h and .cc files for EgammaElectronProducers #28746
Conversation
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-28746/13379
|
A new Pull Request was created by @guitargeek (Jonas Rembser) for master. It involves the following packages: RecoEgamma/EgammaElectronProducers @perrotta, @cmsbuild, @slava77 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
@cmsbuild please test |
The tests are being triggered in jenkins. |
} | ||
|
||
event.put(std::move(electrons)); | ||
event.emplace(putToken_, electrons); |
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.
Just to note that this will call the copy constructor of reco::GsfElectronCoreCollection
inside emplace()
. Using move
like
event.emplace(putToken_, std::move(electrons));
would use the move constructor (that would be much cheaper for e.g. std::vector
s).
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.
Thanks @makortel for the heads up and taking care! I'm changing that of course.
+1 |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
@cmsbuild please test |
The tests are being triggered in jenkins. |
+1 |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
#include "DataFormats/EgammaCandidates/interface/GsfElectronCore.h" | ||
#include "DataFormats/ParticleFlowReco/interface/GsfPFRecTrack.h" | ||
#include "DataFormats/GsfTrackReco/interface/GsfTrack.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.
Why are you removing these include's? Are you relying on them being included through GsfElectronCore.h
?
I would personally further add GsfTrackFwd.h
, for completeness.
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.
Again, correct me if I'm wrong, but I think these *Fwd.h
are not meant to be included in *.cc
files, and that's why I removed them. Indeed, I'm relying here on the indirect include via GsfElectronCore.h
which I think is fine because the *Track objects in this producer are only used as arguments for GsfElectronCore
constructors or member functions, so we can rely on GsfElectronCore.h
to have the good typedefs imported to use it's own functions. Is that OK for you?
#include "CommonTools/CandAlgos/interface/ModifyObjectValueBase.h" | ||
#include "DataFormats/Common/interface/ValueMap.h" | ||
#include "DataFormats/EgammaCandidates/interface/GsfElectron.h" | ||
#include "DataFormats/ParticleFlowCandidate/interface/PFCandidate.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.
What about
#include "DataFormats/EgammaCandidates/interface/GsfElectronFwd.h"
#include "DataFormats/ParticleFlowCandidate/interface/PFCandidateFwd.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.
GsfElectronFwd.h
is already correctly imported in GsfElectron.h
and PFCandidateFwd.h
is already correctly imported in PFCandidate.h
.
#include "DataFormats/EgammaCandidates/interface/GsfElectronCore.h" | ||
#include "DataFormats/ParticleFlowReco/interface/GsfPFRecTrack.h" | ||
#include "DataFormats/GsfTrackReco/interface/GsfTrack.h" | ||
#include "DataFormats/EgammaReco/interface/SuperClusterFwd.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.
Why are these two include's removed?
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.
The include of ElectronSeedFwd.h
is removed because this is already correctly included in ElectronSeed.h
. The SuperCluster include is removed because again it's a Fwd
and we only use the reco::SuperClusterRef
as an argument for one of the member functions in GsfElectronCore
[1]. So again I think it's fair to get this definition indirectly via GsfElectronCore.h
.
if (!eleCore->ecalDrivenSeed()) { | ||
delete eleCore; | ||
if (!eleCore.ecalDrivenSeed()) { | ||
electrons.pop_back(); |
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.
Why not checking first if gsfTrackRef.ecalDrivenSeed()
, and then emplace_back
only in that case?
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.
Good idea, but it turns out the GsfTrack
does not have this member function, so one would have to reproduce the logic from the GsfElectronCore producer I think [1]. I'm not really sure that we can find a quick and safe solution without code duplication in the scope of this PR, or do you have any idea?
[1] https://github.com/cms-sw/cmssw/blob/master/DataFormats/EgammaCandidates/src/GsfElectronCore.cc#L15
@@ -1,62 +1,79 @@ | |||
#include "DataFormats/EgammaCandidates/interface/GsfElectronCore.h" | |||
#include "DataFormats/EgammaCandidates/interface/GsfElectronCoreFwd.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.
Still missing the point why these includes are removed, as well as SuperClusterFwd.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.
Someone correct me if I'm wrong, but here is the line of thought I had:
In general, the point of forward declarations is to keep header files light. This LowPtGsfElectronCoreProducer.cc
is not a header file and therefore the actual GsfElectronCore.h
is needed instead of GsfElectronCoreFwd.h
. This makes GsfElectronCoreFwd.h
superfluous because it's already included in GsfElectronCore.h
[1], like it should be to get the typedefs.
[1] https://github.com/cms-sw/cmssw/blob/master/DataFormats/EgammaCandidates/interface/GsfElectronCore.h
Thank you @guitargeek for checking. About the inclusion of header files: I think to remember that it was recommended to include in every package the headers of all classes needed internally, to avoid troubles in case the header nesting the needed ones got changed. (In our case this doesn't even apply, because as you correctly point out, the same definitions are repeated in the non-forward declared header). |
+1
|
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, @silviodonato, @fabiocos (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
Now that #28429 is merged, it is the moment for a couple of more changes in RecoEgamma/ElectronProducers. One thing I'd like to address is the inheritance of plugins from "BaseProducers", which is something that I think sometimes awkwardly lies between plugin configuration and separate plugins. The
GsfElectronCoreBaseProducer
is one of these instances where it's probably not good to do it: the base producer just manages three products which are not even used by all inheriting producers and has a two-liner member function. Repeating this code in the inheriting producers is actually less verbose than having the base class, while making it clear which products are actually used and also making the transition to global modules easier.Additionally, I apply several modernizations to the ElectronCore producers like the usage of
edm::EDGetTokenT
and also gave a similar treatment to theGEDGsfElectronFinalizer
while at it.PR validation:
CMSSW compiles and local matrix tests pass.
if this PR is a backport please specify the original PR:
No backport intended.