The following are my take on what this wiki page has to say: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Logging
Last update of this page : 12 Nov 2007
Couldn't aggree more ;)
There should be no need for "log core". In my lib, there are no globals:
- the logger keeps all the logging information
- the filter keeps all the filter-related information
You have the ability to make either the logging thread-safe, or the filter, or both. Also, thread-safety can be implemented in many ways: see scenario::usage
Couldn't agree more. I will provide for scoped logging soon.
"Requirement: It should be possible to prevent all or a specified subset of log messages from generating any code, symbols or strings in the object file."
About code/symbols:
I have not tested this extensively, but just in case you want to fully eliminate statements from your code, you should use filter::always_disabled.
Most likely, you'd have something like this:
#ifndef ELIMINATE_LOG_STATEMENTS
BOOST_DECLARE_LOG_FILTER(g_log_filter, some_filter_class)
#else
BOOST_DECLARE_LOG_FILTER(g_log_filter, filter::always_disabled)
#endif
About strings in the object file:
I assume you mean strings like file name, function name, etc.
Note that these are added only if you use tags. So, just don't use these tags when you want this information stripped. Example:
#ifndef ELIMINATE_LOG_STATEMENTS
#define L_ BOOST_LOG_USE_LOG_IF_FILTER(g_l(), g_log_filter()->is_enabled() ) .set_tag( BOOST_LOG_TAG_FILELINE)
#else
#define L_ BOOST_LOG_USE_LOG_IF_FILTER(g_l(), g_log_filter()->is_enabled() )
#endif
- Sink nature (JD) : yes
- Independent output formatting and filtering (JD) : yes
TODO
Done. See tag namespace.
Done. See BOOST_LOG_USE_WCHAR_T (if defined, use wchar_t). Or automatically on Windows, if UNICODE macro is defined.
Filtering support is always provided by the filter. In my lib, the filter is completely separated from the logger.
Don't see the use for this.
I guess this could prove useful. I do see this somehow like this:
template<class T> void throw_and_log(const T & exc) {
DO_SOME_LOGGING;
throw exc;
}
- "In my experience, there are two completely unrelated tasks for logging with quite different requirements. Usually logging libraries map those two to different log levels, but this is not really correct. There are debug messages which need a very high level (like assertion failures) but which are nonetheless completely unneeded and maybe even harmfull in a release build. On the other hand many normal logging messages "user clicked button x" are not really important in most cases and it is cumbersome of having to enable those just to be able to see debug log messages. (Michael Lacher)"
I would assume you could use levels for this.
- "Another useful feature to support: sinks and sources should be independent enough to be able to run in the different processes/machines. It is not uncommon, to have all the logging sent via socket to a different machine where it is extracted from the socket and written on disk. It would be nice if architecture will allow to implement such separation. (Zigmar)"
That's completely doable ;) Just log "raw information" to memory, or to a file/socket, and have another program that just processes that input, and performs user-friendly logging.
Just in case you have a feature you can't live without, let me know : http://torjo.blogspot.com/2007/11/boost-logging-v2-your-killer-feature.html
Copyright John Torjo © 2007
Have a question/ suggestion/ comment? Send me feedback