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
