[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
alp at nuanti.com
Tue Jan 7 20:06:47 PST 2014
On 07/01/2014 18:26, Chris Lattner wrote:
> On Jan 3, 2014, at 4:36 PM, Chandler Carruth <chandlerc at google.com
> <mailto:chandlerc at google.com>> wrote:
>> I just don't see why this substantial complexity and lower
>> performance of AssertingVH is worth having the ability to mix and
>> match NDEBUG and !NDEBUG translation units both in LLVM and in
>> consuming libraries.
>> I thought the motivation was for user code to turn assertions on and
>> off in their code without re-building LLVM to match? That would be
>> addressed by just making the assertions in LLVM keyed off of an
>> LLVM-specific build time flag (like any of the other ABI impacting
>> such flags, for example the particular subset of C++11 supported).
>> Is there some other use case?
> Chandler and I spoke about this a bit on IRC, he convinced me (not
> that I’m the only voice here :) that there isn’t a strong motivation
> for doing this:
Agreed. AssertingVH is not a big deal at the moment, especially once we
get an LLVM_DEBUG macro so it doesn't get hosed due to the target NDEBUG
If someone suggests a tidy way to factor it away though that doesn't
affect performance or readability I'd be supportive.
In general I'm fine with the direction to keep these header conditionals
to a minimum without cracking down on them with an iron fist. Usually
there's a better way to do it and there's an inherent value in keeping
the asserts build as structurally similar to the non-asserts build as
> even today you can build llvm as release+asserts and clang
> debug+asserts, which is the most common mixed mode.
the browser experts
More information about the llvm-dev