Redesigning a debug API

Discussion in 'C++' started by Maxim Yegorushkin, Jul 13, 2005.

  1. On Wed, 13 Jul 2005 14:52:10 +0400, Thomas Lorenz <> 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
    <>
     
    Maxim Yegorushkin, Jul 13, 2005
    #1
    1. Advertising

  2. 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
     
    Thomas Lorenz, Jul 13, 2005
    #2
    1. Advertising

  3. On Wed, 13 Jul 2005 15:47:44 +0400, Thomas Lorenz <> 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
    <>
     
    Maxim Yegorushkin, Jul 13, 2005
    #3
  4. "Maxim Yegorushkin" <> wrote in
    news:eek::

    > 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::eek:stringstream __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
     
    Thomas Lorenz, Jul 13, 2005
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. RonL
    Replies:
    0
    Views:
    781
  2. ringos75
    Replies:
    0
    Views:
    1,001
    ringos75
    Apr 14, 2005
  3. Mike C. Fletcher
    Replies:
    3
    Views:
    1,019
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
    Oct 12, 2003
  4. martinus

    redesigning JUnit asserts

    martinus, Aug 4, 2006, in forum: Java
    Replies:
    0
    Views:
    414
    martinus
    Aug 4, 2006
  5. André
    Replies:
    3
    Views:
    1,679
Loading...

Share This Page