|  | 
        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.