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
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
statement (and alikes) would become a potential source of exceptions. These
issues would complicate user's code if he wants to solve memory allocation
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.