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. Darren