From: Darren Cook (darren_at_[hidden])
Date: 2004-10-25 19:21:32
>>1) The logging code will be in the release build anyway (for all industrial
>>apps I've seen this is the case).
> Some logging is debug only and really shouldn't be in the release
> build. If the mechanism makes the overhead nothing more than a
> Boolean test, without side effect argument evaluation, etc., you
> could leave it in. Even then, each of those conditionals might
> trigger a bad guess by early stages of a process pipeline, so it
> might have deleterious effects on performance.
I agree. I frequently need logging code in an inner loop while trying to
track down a problem. Hhhm, though I suppose I'll remove the log line once
the bug is fixed anyway.
> It may be that the best approach is one that exposes two
> interfaces. One involves a macro that provides the smallest
> runtime overhead. The other might involve one or two C++
> functions or types.
I like this idea. E.g. from Caleb's next mail:
BOOST_LOG (log_name) << the << things << to << output;
BOOST_LOGD (log_name, the << things << to << output);
where the LOGD version can be completely removed in a release build.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk