From: Caleb Epstein <caleb.epstein@gmail.com>
On Mon, 25 Oct 2004 14:41:31 -0400 (EDT), Rob Stewart <stewart@sig.com> wrote:
From: "Jeff Garland" <jeff@crystalclearsoftware.com>
On Fri, 22 Oct 2004 17:16:14 -0400 (EDT), Rob Stewart wrote
There are also plenty of times in which you want logging available in release builds but you want minimal overhead when it is disabled. A macro helps there, too, by moving the evaluation of the argument list into the body of a conditional statement.
Well, personally, I'd really like to try and go macro-less on the logging approach. I don't like macros because:
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 find great utility in being able to leave debug-type logging statements in production code and enable them as-needed when the situation arises (e.g. through sending an extrnal signal or command to a process). This dictates that the "is_enabled" check be very inexpensive, and that when it fails the log message should not even be formatted.
Note that I said "some logging" is debug only. That is, it is specifically not wanted in the release build. I did not mean to imply that all "debug-type" logging should be compiled out. The point is that there should be a choice. Darren Cook's BOOST_LOG and BOOST_LOGD (though I'd name the latter, BOOST_LOG_DEBUG) permits the library user to choose whether to leave the logging in the release build or not.
2) Macro systems tend to be fragile -- pass it bad type (eg:string instead of char*) and it might crash your app. In this day and age the compiler should detect these errors...
If the macro does very little, such as produce a conditional followed by one line of code, there's not much room for this problem. It is also easy to see the definition of such a macro to understand how it works.
This is how the code John submitted works. A logging call looks like:
BOOST_LOG (log_name) << the << things << to << output;
Right. I was including John's version in that description, but it applies more generally. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;