Re: Design question on wrapping a logging library
Dilip wrote:
Victor Bazarov wrote:
Dilip wrote:
[..]
stack, any local variables inside the function will be local to that
thread.. so I basically want to pass the severity information as
some kind of argument to the extractor operator (along with the
message to be logged of course).
Have a 'wrapperObj' _per_thread_ and give it the ability to "flush"
its contents to the real logger (which is a singleton). Then you
could write
myLocalWrapperObj << setSeverity(blah) << "blah...\" << flush;
If you look at my code below, it will be more like
LoggerWrapper() << SEVERITY_WARNING
<< "You have been warned!...\n"
<< LoggerWrapper::flush();
And if you don't care to see things in the log right away, then you
could simply implement the flushing functionality in the destructor,
and use temporary objects. They'll flush as soon as they are killed.
And if you use local objects, they'll flush going out of scope...
If I do that, then if the thread branches to many different method
calls during the course of its processing, do I keep passing around
the wrapperObj everywhere?
Everywhere -- where? If you create it once, as an automatic object,
then pass it around in the same thread, it should be fine. Or you
can recreate it in each function locally. Or you could use a temporary
object:
MyWrapperClass() << setSeverity(blah) << "blah...
I would like to avoid that. Hence my
request to have just one global localwrapper
Huh? Global LOCALwrapper? What's that mean?
obj that will just take
in all kinds of info necessary to cause the ultimate logging.
Realistically apart from severity and the actual message, what else
will I need anyway?
And do it so that outputting 'flush' is an atomic operation.
This went completely over my head. Could you clarify please?
Writing to the global logger has to be portioned, right? And every
write has to be as short as possible not to hold any other logger in
another thread, right? So, if it takes some time to prepare the line
to be output, it needs to be done on thread's own time, and then the
buffer needs to be output to the global logger in a critical section
(although all those things are better discussed in a threading NG).
[..]
For ex: should LogWrapper class derive from ostream or something
like that to inherit the functionality available to cout and
friends?
No, it doesn't have to. Just define operator << for it.
Would you be able to show me a tiny code snippet? Something I can use
to build on..?
template<class T>
LoggerWrapper& operator <<(LoggerWrapper& lw, T const& t);
class LoggerWrapper
{
Logger &globalLogger;
std::string buffer;
Severity severity;
public:
LoggerWrapper(Logger& g)
: globalLogger(g), severity(SEVERITY_INFO) {}
LoggerWrapper& operator << (Severity s) { severity = s; return *this; }
template<class T> friend LoggerWrapper& operator <<(LoggerWrapper&,
T const&);
struct flush {};
void operator << (flush f) {
CRITICAL_SECTION {
globalLogger.writeLine(severity, buffer);
}
buffer.clear();
severity = SEVERITY_INFO;
}
};
template<class T>
LoggerWrapper& operator <<(LoggerWrapper& lw, T const& t)
{
std::ostringstream os;
os << t;
lw.buffer += os.str();
return lw;
}
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask