Boost.Logging Requirements

The following are my take on what this wiki page has to say:

Last update of this page : 12 Nov 2007

Major requirements

Couldn't aggree more ;)

Functional requirements

Thread Safety

There should be no need for "log core". In my lib, there are no globals:

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

Scope logging

Couldn't agree more. I will provide for scoped logging soon.

Eliminate log statemets from generated code (Michael Lacher)

"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:

BOOST_DECLARE_LOG_FILTER(g_log_filter, some_filter_class) 
BOOST_DECLARE_LOG_FILTER(g_log_filter, filter::always_disabled) 

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:

#define L_ BOOST_LOG_USE_LOG_IF_FILTER(g_l(), g_log_filter()->is_enabled() ) .set_tag( BOOST_LOG_TAG_FILELINE)
#define L_ BOOST_LOG_USE_LOG_IF_FILTER(g_l(), g_log_filter()->is_enabled() ) 

Full lazy evaluation (Michael Lacher)

Yup, done.

Sinks (JD)

Exception safety (abingham)


Configurable log message attributes (abingham)

Done. See tag namespace.

The library shall manage i18n (JD)

Done. See BOOST_LOG_USE_WCHAR_T (if defined, use wchar_t). Or automatically on Windows, if UNICODE macro is defined.

Filtering support (Andrey Semashev)

Filtering support is always provided by the filter. In my lib, the filter is completely separated from the logger.

Attribute sets (Andrey Semashev)

Don't see the use for this.

Exception logging support (Andrey Semashev)

I guess this could prove useful. I do see this somehow like this:

template<class T> void throw_and_log(const T & exc) {
    throw exc;

Design Requirements

Configurable log message attributes (JD)

Yes, I do agree. At this time I have formatters, which you call in a different manner, but I guess a wrapper can be provided.

Macro access (JD)

Don't agree. You will need to have a logger defined somewhere. Note that when you define your macros, you can choose which logger you use to log a certain message.

General Thoghths

I would assume you could use levels for this.

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.

Your killer feature...

Just in case you have a feature you can't live without, let me know :

Copyright John Torjo © 2007
Have a question/ suggestion/ comment? Send me feedback