Ben Wheeler wrote:
> 2009/7/3 Pieter Palmers <[email protected]>:
>> Something like this might be even easier:
>>
>> #ifdef __DEBUG__
>> #define IFDEBUG(x) {x;}
>> #else
>> #define IFDEBUG(x)
>> #endif
>>
>> which allows to use:
>>
>> IFDEBUG( qDebug() << "This is some debugging info." );
>
> I still think just
>
> qDebug() << "Blah de blah";
>
> and then switch Qt debug messages on or off as appropriate.
>
> If that control didn't exist, I would still have the test (for whether
> or not to display debug messages) inside the debug print function,
> rather than force every single debug line to wrap itself in a test
> (even a macro). Sure there's an outside chance that if you do
> something like...
>
> mydebug("hello");
>
> void mydebug(char *foo) {
> #ifdef DEBUG
> sprintf(stderr, "%s", foo);
> #endif
> }
>
> .... that when DEBUG is disabled, a very tiny amount of time is being
> wasted calling an empty function. However I'm almost 99% sure that the
> compiler would optimise such calls away, so no time would be wasted at
> all, and a lot of programmers time saved :)
>
>
> Any time you're using some kind of structure in a repetitive way, like
> #ifdef DEBUG
> qDebug()
> #endif
>
> or
> IFDEBUG( qDebug() );
>
> you're pointlessly causing extra work for yourself, and the whole
> structure should be abstracted so it can be called with a single,
> shorter, statement.
The downside of your suggestion is that it's less generic. For example
what if you have multiple arguments:
IFDEBUG( qDebug("This is some debugging info. %s %s", arg1, arg2) );
or if you want to do some sanity checks that don't fit the fairly brutal
ASSERT abort paradigm:
IFDEBUG( if(x<y) qWarning("weird value: %d<%d", x, y) );
In quite some cases such checks are not desirable in non-debug builds
for e.g. performance reasons, but are still desirable to have in the
debug builds to be able to trace weird behavior.
In any case, it's just a suggestion that in my opinion is less work
compared to the original proposal. Probably there are lots of even
better approaches.
Another note on debugging: make sure that you don't call any of these in
realtime sensitive contexts, as they are very likely to mess up your
realtime performance. In such contexts you have to implement a RT-safe
debugging mechanism like it's done in jackd: a lock-free, pre-allocated
and mlock'ed ringbuffer that holds the messages, and that is
periodically emptied by a non-RT thread. And if you have that anyway,
why not use it everywhere?
My few cents,
Pieter
------------------------------------------------------------------------------
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
