[webkit-dev] Easing printf based debugging in WebKit with an helper.

[Brady Eidson]

On Jul 20, 2012, at 7:53 AM, Shezan Baig <shezbaig.wk at gmail.com> wrote:

> On Fri, Jul 20, 2012 at 7:46 AM, Konstantin Tokarev <annulen at yandex.ru> wrote:
>> 
>> 19.07.2012, 22:20, "Filip Pizlo" <fpizlo at apple.com>:
>>> Now consider the stream form:
>>> thingy << "foo " << a << " bar " << someWeirdNonsenseToEnableHex << b << " baz " << c << endl;
>>> This is 8 procedure calls and three string constants. This code will be somewhere around 8 times fatter. Hence, you will be less likely to want to enable such debug statements in release builds both due to fears concerning unnecessary increases in binary size, and unnecessary increases in compile times.
>> 
>> Well, if all << operators are inline, it will be optimized. You also don't have to add endl, because "thingy" can add '\n' and flush buffer at the end by default (like qDebug does)
>> 
> 
> 
> Also, if "START_THINGY" and "END_THINGY" are defined as:
> 
> #define START_THINGY  if (enableDebug) { thingy
> #define END_THINGY    << endl; }
> 
> Then a statement like:
> 
> START_THINGY << "foo " << a << " bar " << someWeirdNonsenseToEnableHex
> << b << " baz " << c << END_THINGY;
> 
> will all be wrapped up within an "if (enableDebug)" condition, which
> we would only turn on when we need the log output, so the cost of the
> streaming/printing can be virtually eliminated even if we decide to
> land the code.

I see in your followup you realized we could further wrap these in #ifndef NDEBUG blocks.  That's all good and well until someone takes a block like...

> This also allows us to do more complex things like:
> 
> START_THINGY << "Selectively printing variables:";
>    if (isSet(someVar1))
>        thingy << " someVar1 = '" << someVar1 << "'";
>    if (isSet(someVar2))
>        thingy << " someVar2 = '" << someVar2 << "'";
> 
>    if (someArray.length()) {
>        thingy << " someArray.items = [";
>        for (int i = 0; i < someArray.length(); ++i) {
>            thingy << someArray[i] << ", ";
>        }
>        thingy << "]";
>    }
> thingy << END_THINGY;

…this and tries to add their own internal #ifndef DEBUG blocks within the statement.  For this reason we tend to keep the "automatically #ifdef NDEBUG protected" utilities like LOG and ASSERT limited to a single statement.

In general this is voluminous code we'd probably not want landed the same way we like dataLog() and LOG() statements to be landed.  But a specific reason we wouldn't want it landed is that It's not at all obvious to a casual observer that this entire block is meant to be debug only.

> And because I'm in the middle of debugging a particular issue, I don't
> really want to create a new type that wraps up those (potentially
> unrelated) variables, just in order to create an overloaded "debug()"
> function that does the pretty printing.

I'm not quite sure what your point is here.

- If you mean you don't want to be hassled by added a new template for a super long debug statement - debug(a, b, c, d, e, f, g, h, i, j, k, l) when the built in utility only supports up through k - then that seems somewhat silly as doing so would be simple and mechanical.

- If you mean you don't want to be hassled to add a new overload for the type you'd like to print, then you'd still have to add a new operator << overload for that type if it didn't already exist.

- If you mean you don't think that debug() statements could be broken up in to multiple lines, of course they can.

debug("Selectively printing variables:";
   if (isSet(someVar1))
	debug("someVar1 = ", someVar1);
   if (isSet(someVar2))
	debug("someVar1 = ", someVar1);
   if (someVector.size())
	debug(" someVector.items = ", someVector);
debug("\n");

Also notice it would be easy to templatize a debug() override to handle the pretty-printing of the vector directly, in addition to other POD and non-class types.

Even without the vector enhancement, this version is simple easier on my eyes as it's not at odds with the entire rest of our code base.

~Brady

> -shez-
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev