search for: somenewvariable

...> A handful of fixes were needed to add support for Release+Assert builds and these are also separate commits. Whoa whoa whoa. Why are you introducing an llvm_assert() macro? The use of assert in header files is not a problem for "libraries", it is things like: #ifndef NDEBUG int SomeNewVariable; #endif in a class. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131111/43c0963c/attachment.html>

On 11/11/2013 07:37, NAKAMURA Takumi wrote: > 2013/11/10 Alp Toker <alp at nuanti.com>: >> #ifndef NDEBUG >> >> This is the biggest violation. NDEBUG should only ever be used in source >> files. That way if something is crashing we can swap in a debug build >> without rebuilding every single dependent application. Win! > I wish; > > - NDEBUG may

...support for Release+Assert >> builds and these are also separate commits. > > Whoa whoa whoa. Why are you introducing an llvm_assert() macro? The > use of assert in header files is not a problem for "libraries", it is > things like: > > #ifndef NDEBUG > int SomeNewVariable; > #endif They're both are a problem. assert() is defined deep down in the C library headers and is conditional on !NDEBUG. It's not practical to override the preprocessor define, at least with the MSVC and OS X headers. (It _might_ be possible to hack around with glibc headers but I...

...sert >>> builds and these are also separate commits. >> Whoa whoa whoa. Why are you introducing an llvm_assert() macro? The >> use of assert in header files is not a problem for "libraries", it is >> things like: >> >> #ifndef NDEBUG >> int SomeNewVariable; >> #endif > They're both are a problem. assert() is defined deep down in the C > library headers and is conditional on !NDEBUG. It's not practical to > override the preprocessor define, at least with the MSVC and OS X > headers. (It _might_ be possible to hack around with...