Replace a lot of 'static const' with 'constexpr' or 'const'.
'static const' means, there must be at most one of these, and initialize it at
compile time if possible or runtime if necessary. This leads to unexpected
code execution, and TSAN* will complain about races on the guard variables.
Generally 'constexpr' or 'const' are better choices. Neither can cause races:
they're either intialized at compile time (constexpr) or intialized each time
independently (const).
This CL prefers constexpr where possible, and uses const where not. It even
prefers constexpr over const where they don't make a difference... I want to have
lots of examples of constexpr for people to see and mimic.
The scoped-to-class static has nothing to do with any of this, and is not changed.
* Not yet on the bots, which use an older TSAN.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2300623005
Review-Url: https://codereview.chromium.org/2300623005
diff --git a/gm/texturedomaineffect.cpp b/gm/texturedomaineffect.cpp
index ba574b6..2dd340e 100644
--- a/gm/texturedomaineffect.cpp
+++ b/gm/texturedomaineffect.cpp
@@ -138,19 +138,15 @@
}
private:
- static const SkScalar kDrawPad;
- static const SkScalar kTestPad;
- static const int kTargetWidth = 100;
- static const int kTargetHeight = 100;
+ static constexpr SkScalar kDrawPad = 10.f;
+ static constexpr SkScalar kTestPad = 10.f;;
+ static constexpr int kTargetWidth = 100;
+ static constexpr int kTargetHeight = 100;
SkBitmap fBmp;
typedef GM INHERITED;
};
-// Windows builds did not like SkScalar initialization in class :(
-const SkScalar TextureDomainEffect::kDrawPad = 10.f;
-const SkScalar TextureDomainEffect::kTestPad = 10.f;
-
DEF_GM(return new TextureDomainEffect;)
}