> On Apr 20, 2014, at 2:43 PM, Mark Rowe <mr...@apple.com> wrote: > > >> On Apr 20, 2014, at 14:02, Filip Pizlo <fpi...@apple.com> wrote: >> >> The #if means that the code being guarded isn't indented. I believe that >> indenting control flow is a good idea. >> >> Also, using normal if's whenever it would compile and be semantically >> equivalent means that the code being protected would benefit from >> syntax/type/semantic checking even in a release build. > > We use preprocessor defines to distinguish between many things besides debug > and release builds, and in many cases it’s impossible to tell ahead of time > whether the alternate paths will compile on all platforms. This is > particularly true for code guarded by defines related to the compiler, target > platform, or OS version, but is also a concern with feature defines where > symbols have been #if’d out. > >> I think of this as being analogous to our preference for static assertions: >> we use them whenever we can but resort to dynamic assertions when we can't. > > I don’t think this is a great analogy. It’s usually clear from the context > whether what you’re asserting is a compile-time or run-time concept, and thus > whether a compile-time or run-time assertion is appropriate. It’s far from > obvious whether all branches of an if will compile.
In the cases that I'm concerned with, I don't care if the code guarded by ASSERT_DISABLED will compile, only whether it will run. This is mostly, but not entirely, different from CPU guards - even those may be dynamic like in the case of tests for exotic SSE capabilities. I don't think you can make a hard and fast rule based on the compile versus run distinction. You can make one based on semantic equivalence (if it's equivalent then avoid the preprocessor). So, I think that if the only goal here was to make an enforceable rule then my proposal is somewhat better. > > - Mark > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
