On Apr 20, 2014, at 14:50, Filip Pizlo <fpi...@apple.com> wrote: > > >> 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’m not sure what you’re trying to say here. Surely you care that the code compiles without warnings, since otherwise you’d break the build. Can you elaborate on the difference you see between ASSERT_DISABLED checks and platform-related checks (OS, OS version, CPU architecture, etc), and what impact that difference has on your proposal? > 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. I’m not sure exactly what you mean by semantic equivalence here. #if vs if inherently have different semantics. - Mark
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
