Boost C++ Libraries

...one of the most highly regarded and expertly designed C++ library projects in the world. Herb Sutter and Andrei Alexandrescu, C++ Coding Standards

PrevUpHomeNext

Rationale and FAQ

Why string literals as scope names?
Why scoped attributes don't override existing attributes?
Why log records are weakly ordered in a multithreaded application?
Why attributes set with stream manipulators do not participate in filtering?
Why not using lazy streaming?
Why not using hierarchy of loggers, like in log4j? Why not Boost.Log4j? Etc.
Does Boost.Log support process forking?
Does Boost.Log support logging at process initialization and termination?
Why my application crashes on process termination when file sinks are used?
Why my application fails to link with Boost.Log? What's the fuss about library namespaces?
Why MSVC 2010 fails to link the library with error LNK1123: failure during conversion to COFF: file invalid or corrupt?

One may wonder why not allow arbitrary strings to be used as named scope names. The answer is simple: for performance and safety reasons. Named scope support functionality has one significant difference from other attribute-related features of the library. The scope stack is maintained even when no logging is done, so if a function foo has a BOOST_LOG_FUNCTION() statement in its body, it is always a slowdown. Allowing the scope name to be an arbitrary string would make the slowdown significantly greater because of the need to allocate memory and copy the string (not to mention that there would be a need to previously format it, which also takes its toll).

Dynamic memory allocation also introduces exception safety issues: the BOOST_LOG_FUNCTION() statement (and alikes) would become a potential source of exceptions. These issues would complicate user's code if he wants to solve memory allocation problems gracefully.

One possible alternative solution would be pooling pre-formatted and pre-allocated scope names somewhere but this would surely degrade performance even more and introduce the problem of detecting when to update or free pooled strings.

Therefore restricting to string literals seemed to be the optimal decision, which reduced dynamic memory usage and provided enough flexibility for common needs.


PrevUpHomeNext