On the topic of string logging handlers, I thought this might be of interest, possibly for future improvements to Log4cxx.
_bstr_t is a COM string class, that will maintain a NULL string representation if created with one. (I don't know how the STL string behaves, but the MFC CString keeps an empty string, "", instead of NULL.) Logging this will crash my program: _bstr_t sMyStr(NULL); LOG4CXX_DEBUG(MyLogger, sMyStr); Log4cxx delegates the logging of "sMyStr" to std::ostream, which invokes the "char*" cast operator, and then tries to do a "strlen" on the value. Because the value is NULL, I get a crash. My solution to avoiding the crash was to implement "<<" operators for _bstr_t, with "MessageBuffer", "WideMessageBuffer", "CharMessageBuffer", and also "std::basic_ostream<...>" as lvalues. In my implementations that involve delegating to the ostream, I check for NULL (after the cast) before forwarding to the ostream. But since I can't implement an operator for everything someone might log, I redefined the LOG4CXX_* macros to wrap all logging calls in a try/catch(...) block. (If a logging system is going to fail, it should above all, not bring the program down.) In benchmarks, I didn't see any performance difference with and without the try/catch, using MS VC++ 7. If any log4cxx developers are listening, I think it might be nice to incorporate a try/catch blocks into these macros in a future version. If anyone has alternate solutions, I'd be interested to hear them. Mike