Re:Files UWP: An enthusiast’s take on what Windows File Expl...
by Sharlin on Saturday June 08, 2019 @05:40AM
(#20131516)
Huh? The function is a no-op. The compiler should optimize it into nothingness, but optimization is not the point here. Or was that an attempt at humor?
[ Parent
| on HN ]
Re:Files UWP: An enthusiast’s take on what Windows File Expl...
by saagarjha on Saturday June 08, 2019 @05:47AM
(#20131555)
I don't know how much the C# compiler optimizes code, if it does at all, but I do know that the JIT compiler is smart enough to delete this. So I came up with an awkwardly-worded response that provided information that I knew to be true.
Re:Files UWP: An enthusiast’s take on what Windows File Expl...
by Sharlin on Saturday June 08, 2019 @05:48AM
(#20131556)
Yes, of course it is trivially optimized out, that's still not the issue. The question is why that function (and several others) exist in the first place! Is there a bug (which is then copypasted several times) and the code is actually supposed to flip between enabled and disabled (in which case it should really be written foo = !foo)? Or something else?
Re:Files UWP: An enthusiast’s take on what Windows File Expl...
by saagarjha on Saturday June 08, 2019 @05:59AM
(#20131605)
Probably a copy/paste bug that the author overlooked.
Re:Files UWP: An enthusiast’s take on what Windows File Expl...
by Sharlin on Saturday June 08, 2019 @07:11AM
(#20131788)
Which is precisely my point.
Re:Files UWP: An enthusiast’s take on what Windows File Expl...
by anticensor on Saturday June 08, 2019 @12:45PM
(#20133365)
C# has assignment and mentioning overloading by aliasing to getters and setters. The setter may be holding a shared lock and this pattern may make it release.