[Development] QLog ( Work on qDebug and friends)

[BRM]

----- Original Message -----
> From: "kai.koehne at nokia.com" <kai.koehne at nokia.com>
> To: wolfgang.beck at nokia.com; development at qt-project.org
> Cc: 
> Sent: Tuesday, February 7, 2012 2:26 AM
> Subject: Re: [Development] QLog ( Work on qDebug and friends)
> 
> Hi Wolfgang,
> 
> how about making the category a distinct type instead?
> 
> struct QMessageCategory {
>   explicit QMessageCategory(const char *name);
> };
> 
> class QMessageLogger {
>    void debug(const char *format, ...); 
>    void debug(QMessageCategory category, const char *format, ...); 
> }
> 
> 
> ...
> QDebugCategory debugCategory("MyApp"); // You'll typically do this 
> in one place
> ...
> qDebug(debugCategory, "hi there");
> 

+1. 

I think this makes a lot of sense especially if you let people derive from QMessageCategory. So I'd suggest it is a class instead of a structure.
(Yes, I know a 'struct' is just a class that defaults to public; but making it a class now (i) saves a lot of headaches, and (ii) makes it more clear what is intended.)

> From: Oswald Buddenhagen <oswald.buddenhagen at nokia.com>

>On Tue, Feb 07, 2012 at 06:54:55AM +0000, ext wolfgang.beck at nokia.com wrote:
>> I'm working to integrade category log with QMessageLogger & Co and unfortunatelly we can not use
>> qDebg(<category>) << "my message" because there is already a debug(const char *msg, ...) function
>> combining with the macro 
>> #define qDebug QMessageLogger(__FILE__, __LINE__, Q_FUNC_INFO).debug.
>> 
>> So I use a new function and macro:
>>     QDebug debug();
>>     QDebug debugCategory(const char *msg);
>>     QDebug warning();
>>     QDebug warningCategory(const char *msg);
>>     QDebug critical();
>>     QDebug criticalCategory(const char *msg);
>>     QDebug fatalCategory(const char *msg);
>> 
>> #define qDebugCat(category) QMessageLogger(__FILE__, __LINE__, Q_FUNC_INFO).debugCategory(#category)
>> #define qWarningCat(category) QMessageLogger(__FILE__, __LINE__, Q_FUNC_INFO).warningCategory(#category)
>> #define qCriticalCat(category) QMessageLogger(__FILE__, __LINE__, Q_FUNC_INFO).criticalCategory(#category)
>> #define qFatalCat(category) QMessageLogger(__FILE__, __LINE__, Q_FUNC_INFO).fatalCategory(#category)
>> 
>> Any problems with this naming conventions???
>> 
>yes. they suggest that you are getting a category back. a proper verbose
>name would be fooWithCategory or possibly categorizedFoo.


+1


>the fatal cat certainly has entertainment value, but is not necessarily
>good api.


Certainly the case.


>i'd actually suggest going the microsoft route and naming the functions
>qFooEx or something similarly undescriptive. then it's clear that it's
>"just an overload".


-1

We're not Microsoft; and I always thought that was bad API design itself as what happens the next time you need to extend it? qFooExEx?
No. Just come up with a new, proper name for it in the first place.


>fwiw, the right solution would of course be renaming the existing
>qFoo(const char *) to qPrintFoo(const char *) - the overloading always
>seemed weird to me anyway (especially as the stream variant works only
>with qdebug.h, while the print variant "just works"). unfortunately,
>this is not source compatible.


Guess its just to C++--ify it; but yeah, I agree. That said; I think the use of QMessageCategory can certainly clean that up.
If done right, one could use the << to generate several different category messages in a row.

Ben