[LLVMdev] Proposal for better assertions in LLVM

[Talin]

On Tue, Aug 9, 2011 at 1:59 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Aug 8, 2011, at 10:46 PM, Talin wrote:
>
> > So I went ahead and implemented this in my own frontend - I've been using
> it for both assertions and conditional debug statements. I like it quite a
> bit, and like you say, it compiles down to nothing in non-debug builds.
>
> Does:
>   YOUR_DEBUG_MACRO(…) << some_out_of_line_function();
>
> Still evaluate the out of line function?  If so, it seems that something
> like the LLVM "DEBUG" macro is a better approach.
>

No it does not. Basically the macro expands to a ternary operator:

    (expression) ? (void)0 : VoidResult & Stream

Because the precedence of ?: is lower than <<, all of the stream operators
get associated with the stream object, rather than with the expression as a
whole. And C++ guarantees that no side effects will happen for the right
hand side if the expression is true. So none of the stream operators or
their arguments get evaluated.

The "VoidResult" is there because both sides of a ternary operator have to
be the same type, which in this case we want it to be type void. There's an
overloaded operator& which takes (VoidResult, Stream) and returns a void.
It's inline and does nothing. Since the precedence of & is lower than <<, we
still get all of the stream operators attaching to the stream object.

However, if you think that's too magical, let me suggest something much less
grandiose. Before I started using these new debug macros, my older debug
macros looked like this:

   DASSERT(expression);
   DASSERT_ARG(expression, arg);

The DASSERT_ARG macro prints "assertion failed: <expression>, context:
<arg>". "arg" can be any object that is streamable to a raw_ostream. This
allows me to know a little bit more information about the failure, such as
which type or variable was involved.


> -Chris




-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110809/c87a5be7/attachment.html>