Re: Output levels
Posted: Mon Jul 11, 2011 10:50 am
As you may have noticed, I created an "output" branch this weekend and will start working on this. I won't spend too much time on this, because everyone will be asked to polish their output themselves in future. I just try to get more or less useful output in console and logfile.
Additionally I came to a conclusion about different questions that were raised in this thread:
Any objections against this?
outlook:
In future I can imagine a more fundamental change of the output system (but then no changes to the output itself ), including thread safety. For example we could have a more STL-compliant system which uses manipulators. this could look like this:
However I'm not sure if everyone would like this notation...
Everyone please share your opinion, both about the current decisions and the future suggestions.
Additionally I came to a conclusion about different questions that were raised in this thread:
- The output levels will be defined as in the second post of this thread. Their corresponding numbers will probably start at 1, while 0 is (forced) debug output (instead of -1)
- Contexts will be defined as bitmasks (that's also why it's not so good to use -1 as debug output level)
- The idea to use different macros for different output levels (e.g. COUT() and LOG()) is dropped because the output levels define only the importance and meaning of the message, but whether it appears in the console, the logfile, or somewhere else depends on the user's configuration. Therefore all output should use the same function/macro
- Using different macros in the form of COUT_USER() and COUT_INTERNAL() is also not a good idea because there's no difference in typing between COUT(USER_ERROR) and COUT_USER(ERROR), but the latter requires the definition of ERROR which is dangerous.
- No threadsafety for the moment
Any objections against this?
outlook:
In future I can imagine a more fundamental change of the output system (but then no changes to the output itself ), including thread safety. For example we could have a more STL-compliant system which uses manipulators. this could look like this:
Code: Select all
orxout << user_error << "Some text" << std::endl;
orxout << threaded << verbose << context(network) << "asdfasdf" << std::endl;
Everyone please share your opinion, both about the current decisions and the future suggestions.