[cfe-dev] Goal for 3.5: Library-friendly headers

[Alp Toker]

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 
setting.

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 
possible.

Alp.



> even today you can build llvm as release+asserts and clang 
> debug+asserts, which is the most common mixed mode.
>
> -Chris

-- 
http://www.nuanti.com
the browser experts