But I do want a debugging utility to does land, is always compiled in, and that
everyone enjoys using.
-Filip
On Jul 19, 2012, at 11:37 AM, Alexis Menard <alexis.men...@openbossa.org> wrote:
> On Thu, Jul 19, 2012 at 3:20 PM, Filip Pizlo <fpi...@apple.com> wrote:
>> 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.
>
> As the Changelog said in the patch, thingy() << ... are not meant to
> land but to help you locally.
>
>>
>> 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;
>
> Ok you give me a valid example (and nice looking) for you in JSC.
> Nobody force you to use the thingy if you don't like it. It seems low
> level printf is better for you, great!
>
> Now see another use case :
>
> LayoutRect rect;
> printf("Rect is %i %i %i %i, rect.x(), rect().y(), rect.width(),
> rect.height());
>
> for me to get the rect values.
>
> thingy() << rect; (as LayoutRect could have a << overload, I give an
> example in the patch with IntRect)
>
> Granted we can achieve it with a
>
> printf("Rect is %s", debug(rect)); same provided that debug() for a
> LayoutRect is implemented.
>
> One way or another I'm fine. I just want to ease the process here.
>
>>
>> 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.
>
> As I said, we do not want to land these thingy() <<.
>
>>
>> And I'm not even going to start complaining about how unnatural it is to set
>> padding preferences, switch to hex, etc.
>
> Which is not what the class is meant to solve.
>
>>
>> -Filip
>>
>> On Jul 19, 2012, at 10:53 AM, Andreas Kling <kl...@webkit.org> wrote:
>>
>> On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson <beid...@apple.com> wrote:
>>>
>>>
>>> On Jul 10, 2012, at 5:25 AM, Alexis Menard <alexis.men...@openbossa.org>
>>> wrote:
>>>
>>>> On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson <beid...@apple.com> wrote:
>>>>>
>>>>> On Jul 9, 2012, at 2:43 PM, Alexis Menard <alexis.men...@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@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
>
>
>
> --
> Alexis Menard (darktears)
> Software Engineer
> openBossa @ INdT - Instituto Nokia de Tecnologia
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
