remove lazy cache from surface

[VinInn]

Following the Report from Chris

The Default Constructor seems used

[cmsbuild]

A new Pull Request was created by @VinInn (Vincenzo Innocente) for CMSSW_7_1_X.

remove lazy cache from surface

It involves the following packages:

DataFormats/GeometrySurface

@cmsbuild, @civanch, @Degano, @mdhildreth, @nclopezo can you please review it and eventually sign? Thanks.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
@nclopezo, @ktf you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

[civanch]

Hi Vincenzo,
do you really want this line:
if ((thePos.x() == 0.) & (thePos.y() == 0.)) {

[VinInn]

On 8 May, 2014, at 5:43 PM, Vladimir Ivantchenko notifications@github.com wrote:

Hi Vincenzo,
do you really want this line:
if ((thePos.x() == 0.) & (thePos.y() == 0.)) {
yes
was there and the comment states why
v.

[civanch]

I mean you may be want
if ((thePos.x() == 0.) && (thePos.y() == 0.)) {

[VinInn]

On 8 May, 2014, at 6:11 PM, Vladimir Ivantchenko notifications@github.com wrote:

I mean you may be want
if ((thePos.x() == 0.) && (thePos.y() == 0.)) {

no
& is faster
v.

[civanch]

+1
progress is going.. should && -> & be done everywhere?

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_1_X IBs unless changes or unless it breaks tests. @nclopezo, @ktf can you please take care of it?

[VinInn]

On 8 May, 2014, at 6:41 PM, Vladimir Ivantchenko notifications@github.com wrote:

+1
progress is going.. should && -> & be done everywhere?
only when left and right operands are simple (one instruction) and of course both valid ( p && p->f() is of course still mandatory: & will segfault if p==nullptr)

if one is heavy and one is light, or one is very probable and the other rare etc &&, || can still make the code faster
(typical: std::abs(v.z())< zcut && deltaPhi(v,phi(),phi0) < phicut)
in this case of course better to first evaluate the fast one and avoid to call atan2 in case it fails

v.

[cmsbuild]

+1
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-3742/1382/summary.html

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_1_X IBs unless changes (tests are also fine). @nclopezo, @ktf can you please take care of it?

[cmsbuild]

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-3742/1382/summary.html

[smuzaffar]

@VinInn , I am testing llvm 14 and see many warnings of type -Wbitwise-instead-of-logical [a]. What would you suggest here? Should we just replace bitwise operators with logical ?

[a]

grep ': warning:' build.log | grep CMSSW_12_5_CLANG_X_2022-08-17-2300/src/ | sort | uniq  | grep -v 'bitwise-instead-of-logical' |wc -l
215
   1050 DataFormats/GeometrySurface/interface/SimpleDiskBounds.h:21:13: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical]
   1050 DataFormats/GeometrySurface/interface/SimpleDiskBounds.h:22:13: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical]
   1578 DataFormats/TrackerRecHit2D/interface/trackerHitRTTI.h:30:13: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
   1581 DataFormats/TrackerRecHit2D/interface/trackerHitRTTI.h:31:12: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
   1581 DataFormats/TrackerRecHit2D/interface/trackerHitRTTI.h:35:64: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical]
   1581 DataFormats/TrackerRecHit2D/interface/trackerHitRTTI.h:36:62: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
   1581 DataFormats/TrackerRecHit2D/interface/trackerHitRTTI.h:37:58: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical]
   1581 DataFormats/TrackerRecHit2D/interface/trackerHitRTTI.h:39:14: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical]
   1584 DataFormats/TrackerRecHit2D/interface/trackerHitRTTI.h:36:63: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical]
   1584 DataFormats/TrackerRecHit2D/interface/trackerHitRTTI.h:39:13: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
  12924 DataFormats/GeometrySurface/interface/GloballyPositioned.h:157:9: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical]

[ktf]

Github does not forget! :-) I hope you guys are doing well!

[VinInn]

again:
The use of bitwise operators IS intentional!
logical operators force the compiler to evaluate them in sequence as the following maybe ill formed if previous fails
(for instance p&&(*p).ok()) and introduce branches while bitwise operators can be evaluated in any order (even in parallel) and do not require branches.
I'm very sorry for llvm.