That does not eliminiate any overhead that may exist due to evaluating the function arguments prior to making the call, nor any potential side effects of those expressions.
Personally, having debugging log statements completely disappear from the source code in a release build is more comforting, even if it involves a macro.
In my lib, you say something like: BOOST_LOG(gui) << "cursor at " << x << "," << y; You can, at run-time, enable and/or disable logs. Thus, the above is equivalent to: // pseudo-code if ( is_log_enabled(gui_log) ) log(gui_log) << "cursor at " << x << "," << y; Thus, the overhead of computing the string to output happens only if the log is enabled. I think this is much more flexible (than having a compile-time switch). Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html