By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,925 Members | 1,129 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,925 IT Pros & Developers. It's quick & easy.

Redesigning a debug API

P: n/a
Hello NG,

I'm working on a larger C++ project with it's own debug functionality. The
typical debug call looks like this:

DEBUG(WARNING, "An error " << getErrorCategory() << " occured.");

The debug API consists of some complex macros. The macro aquires a debug
stream and pipes the second argument into that stream.

For several reasons I'm trying to get rid of those macros and replace them
with ordinary functions.

The problem: I can't refactor all debug calls. So the function should b
able to take arguments exactly like the makro above:

dbg::debug(WARNING, "An error " << getErrorCategory() << " occured.");

Any chance to make this happen? Somehow I must convince the compiler to
convert "An error " into some kind of object before streaming the rest of
the expression.

Transforming the whole mess into something nicer like

dbg::debug(WARNING) << "An error " << getErrorCategory() << " occured.";

But this wouldn't work, because I have to lock the stream for the complete
write, free the lock after writing the last item and flush the stream...

Any ideas?

Thanks
Thomas
Jul 23 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
On Wed, 13 Jul 2005 14:52:10 +0400, Thomas Lorenz <Lo******@gmx.de> wrote:
Hello NG,

I'm working on a larger C++ project with it's own debug functionality.
The
typical debug call looks like this:

DEBUG(WARNING, "An error " << getErrorCategory() << " occured.");

The debug API consists of some complex macros. The macro aquires a debug
stream and pipes the second argument into that stream.

For several reasons I'm trying to get rid of those macros and replace
them with ordinary functions.


There is a slight chance you really want to do that. For the most part one
wants to completely skip evaluation of trace output arguments if it's not
going to make it into a log. The fastest way to do this is to use an if
statement. Writing if statements all over is boring, so you'll probably
end up using macros, something like this:

#define LOG_DETAIL_DO_LOG(lg, lvl, msg...) \
do { if((lg).does_accept(logging::lvl)) (lg)(__FILE__, __LINE__, msg);
} while(0)

#define LOG_DBG(lg, msg...) LOG_DETAIL_DO_LOG(lg, log_dbg, msg)

--
Maxim Yegorushkin
<fi****************@gmail.com>
Jul 23 '05 #2

P: n/a
"Maxim Yegorushkin" <fi****************@gmail.com> wrote in
news:op***************@localhost.localdomain:
There is a slight chance you really want to do that. For the most part
one wants to completely skip evaluation of trace output arguments if
it's not going to make it into a log. The fastest way to do this is
to use an if statement. Writing if statements all over is boring, so
you'll probably end up using macros, something like this:

#define LOG_DETAIL_DO_LOG(lg, lvl, msg...) \
do { if((lg).does_accept(logging::lvl)) (lg)(__FILE__, __LINE__,
msg);
} while(0)

#define LOG_DBG(lg, msg...) LOG_DETAIL_DO_LOG(lg, log_dbg, msg)


That's right - but log level evaluation can also happen in the debug
function. OK, that leaves the slight overhead of the function call.

But using functions would allow me to perform other optimizations. Because
of the convoluted streaming taking place everywhere in the code, the DEBUG
macro looks like this:

#define DEBUG(level,out) \
{ \
std::ostringstream __o; \
__o << out; \
dbg::debug(level, __o.str()); \
}

But lots of the debug statements are plain text output:

DEBUG(INFO, "I'm at function foo()");

So the stringstream would not be necessary if the second parameter is a
string or can be converted into a string. Since macros are not type aware I
can't otimize for simple cases :(

Thomas
Jul 23 '05 #3

P: n/a
On Wed, 13 Jul 2005 15:47:44 +0400, Thomas Lorenz <Lo******@gmx.de> wrote:

Thomas, you might like taking a look at boost logging library which is
being developed now to get some ideas. Google for boost logging.

--
Maxim Yegorushkin
<fi****************@gmail.com>
Jul 23 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.