[Bug 41199] [patch] Enhance logging system

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41199

--- Comment #5 from Olli Salli <ollisal at gmail.com> 2011-09-26 06:46:50 PDT ---
(In reply to comment #4)
> > 1) you can't use the QString overload of the QDebug ctor (when to send the
> > string forward?)
> 
> The problem of passing the QString to the constructor of QDebug in
> enabledDebug/enabledWarning is that at the end of the method the string will be
> something like "tp-qt4 " PACKAGE_VERSION " DEBUG:" and I see no way to return
> the string after the operator<<() has been called for all the debug or to know
> when the string has been filled with the debug info.
> 
> Moreover if I create the QString inside enabledDebug it will be destroyed when
> the method exits, causing sigsegv for the following operator<<()s.
> 
> So you can either:
> a) Use a pointer and allocate it on the heap, but it will be likely to leak the
> string because I see no way to know when it can be destroyed
> b) Pass the string to the enabledDebug method, but it will break ABI
> c) Use a static QString, but it might be a issue for multithreaded apps.

Yes, which is why I said that you can't use that ctor.

> 
> 
> > 2) even if you use the QIODevice overload with some QIODevice guaranteedly
> > outliving the debug object (such as a static object), you'll lose the
> > boundaries between the debug messages - those being signaled by (Q)Debug
> > object destruction. Note that some debug messages are legitimately
> > multi-line. This might or might not be a problem to you, but I'd rather
> > preserve them if anybody wants to do anything more specific than raw output
> > to console or a file with them. (Think sending to an event log with
> > timestamps per warning event, for example).
> 
> In my opinion this approach is safer because it simply consists in redirecting
> the debug into another QDebug, handled by the main application instead of by
> the library itself... The library doesn't need to care about when this QDebug
> is destroyed, because it will be destroyed like every other QDebug when it goes
> out of scope, that means after all the operator<<() are called.
> You will still get the multiline debug in just one QDebug, exactly in the same
> way that you get it using qDebug() in enabledDebug.
> Until your output is generated by just one debug() call, then it will be
> redirected all together in the QDebug returned by the callback method.

If you take care in reading what I wrote, both approaches in implementing the
debug callback are faulty to me because the callback's role is wrong, and
neither was proposed by me. 1 and 2 in my previous post are two specific
problems in the approach where your "debug callback" constructs the QDebug
instance i.e. rationale AGAINST that approach completely.

Are you following me with the (to me, anyway) still most flexible approach? I
even described the implementation and the specific signature for the callback
in comment 1. Having reasoned that such an approach is possible with no added
complexity, I'm definitely not going to ever apply any patch based on an
approach where I can readily identify these drawbacks.

Otherwise, I'm going to implement the more flexible approach myself, but can't
give you any guarantees on WHEN that would happen.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.