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

[Filip Pizlo]

One reason for preferring printf syntax is that it results in dramatically more compact code. In JSC we take advantage of this to have debug printf support built even in release builds. So or example if you want CodeBlock to print itself in a release build, you don't first have to #define a bunch of things - the relevant method is already built. 

The reason for the compactness is the number of calls for a typical printing action. Consider this:

dataLog("foo %d bar %x baz %p\n", a, b, c);

This is one procedure call and one string constant. Note that the machine code to get the string constant is often as big as a procedure call, on some platforms. 

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.

And I'm not even going to start complaining about how unnatural it is to set padding preferences, switch to hex, etc. 

-Filip

On Jul 19, 2012, at 10:53 AM, Andreas Kling <kling at webkit.org> wrote:

> On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson <beidson at apple.com> wrote:
>> 
>> On Jul 10, 2012, at 5:25 AM, Alexis Menard <alexis.menard at openbossa.org> wrote:
>> 
>> > On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson <beidson at apple.com> wrote:
>> >>
>> >> On Jul 9, 2012, at 2:43 PM, Alexis Menard <alexis.menard at openbossa.org> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> For those who "secretly" use printf debugging :). I know the
>> >>> recommended way is to use a debugger and it's not the point of this
>> >>> discussion.
>> >>
>> >> A lot of us do this, and sometimes it's necessary.  I agree with the gripe and support adding something easier.
>> >>
>> >>> So I propose wtf() and its stream operator.
>> >>>
>> >>> Usage :
>> >>>
>> >>> wtf()<<"Hello"<<"World"<<3<<4.53322323; will output : Hello World 3 4.53322
>> >>
>> >> There is no reason to bring in stream operators - that are willfully absent from WebCore - just for debugging.
>> >>
>> >
>> > But it's really nice for that purpose, and somehow match std::cout
>> 
>> And we quite purposefully don't use std::cout in the project.
>> 
>> >> Overloading functions works just as well.
>> >
>> > I'm not sure to understand what you mean here…
>> 
>> I mean relying on C++'s overloading of functions for the different types you'd like to printf debug.
>> 
>> void debug(WebCore::String&);
>> void debug(WebCore::Frame*);
>> void debug(WebCore::Node*);
>> 
>> etc etc etc.
>> 
>> debug(someFrame);
>> debug(someNode);
>> debug(someString);
>> 
>> Especially that last one would help me from remembering how to type "printf("%s", someString.utf8().data())" which is all I've ever really wanted.
> 
> Hello fellow printfers!
> 
> While I'm just as ashamed of my printf habits as the next guy, I think it'd be great if we could move forward with this somehow.
> 
> Coming from a background in Qt, the stream operator syntax looks perfectly normal to me, perhaps you could expand on why we want to avoid using these in WebKit. Is there a technical reason, or is it more of a language purity issue?
> 
> Regardless, adding a consistent set of debug(WebCore::MyCoolOverload) methods as suggested would still be massively useful.
> 
> -Kling
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120719/2a1abe15/attachment.html>