On Jul 20, 2012, at 7:53 AM, Shezan Baig <shezbaig...@gmail.com> wrote:
> On Fri, Jul 20, 2012 at 7:46 AM, Konstantin Tokarev <annu...@yandex.ru> wrote:
>>
>> 19.07.2012, 22:20, "Filip Pizlo" <fpi...@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@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
