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. On Wed, Jul 27, 2011 at 4:00 PM, Chandler Carruth <chandlerc at google.com>wrote:> On Wed, Jul 27, 2011 at 3:31 PM, Talin <viridia at gmail.com> wrote: > >> Can you explain how it avoids evaluating the arguments in the false case? >> I looked at the code but it's pretty complex. >> > > Essentially it expands to something like: > > !(Ty == STy) ? (void)0 : Voidifier() & llvm::dbgs() << ... > > where you have something vaguely along the lines of > > struct Voidifier { > void operator&(raw_ostream &); > }; > > The conditional expression ensures that the side-effects of the LHS and RHS > are contained, while allowing the convenient syntax. The voidifier hack is > just for types, there are other simple ways to phrase it that boil down to > the same construct. You could also implement it in LLVM as: > > if (!(Ty == STy)) {} else llvm::dbgs() > > which works as long as its not used as the lone statement in an unbraced > else statement. > > The existing implementations are much more complex in order to support > various different constructs. Something like the above would likely serve > LLVM's needs. Again, I'm happy to provide a very minimal implementation for > consideration if there is interest, I'm just not sure there is interest. >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110808/aeac2de7/attachment.html>
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. -Chris
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>