Hmm, I honestly think that having "loggers as class members" is a bad idea.
And I find it extremely useful. In fact, I tend to avoid making loggers irrelevant to some sensible entity in the program. For example, if I have a class that implements a network connection, I would most likely make logger a member of this class. This allows to seemlessly embed information related to this connection into log records. In consequence, this allows to apply filtering based on this information.
Yes, I understand and I am not trying to convert you or anything. Just expressing my view which you might or might not take into account. Design-wise I do not believe a logger should be part of a class. That inclusion of convenience that you describe is unlikely to happen in a more structured development environment (where design is evaluated and approved separately and might be even done by different people). I feel that inclusion certainly goes against the design trend of making classes as clean/small as possible. Implementation-wise, you do not mention if you "make logger a member of this class" as a static member. If it is not static, then the associated overhead is not acceptable (I have about 30,000 objects). As a static member it is not greatly different from a file-scope static.
I do not usually like global objects either (static initialization issues, too much visibility). However, what I definitely use a lot is retrieving the same log by name in different compilation modules (that takes the visibility down). Like
boost::log log1(name); boost::log log2(name); // The same as log1
The example above does just that. All you need is to have the BOOST_LOG_DECLARE_GLOBAL_LOGGER in some common header, and include it whenever you need the my_logger logger. The my_logger is a singleton that is accessible from different translation units and even different modules (dlls, sos). It does have static initialization problems solved. This is the key difference from declaring a namespace-scope logger variable.
I have not got that impression that your BOOST_LOG_DECLARE_GLOBAL_LOGGER-based "example above does just that". To start with, I (I'll use "I", "you" for convenience. nothing personal) simply create a logger instance on the spot when I need it. You insist I *declare* first with some hairy :-) macro "in some common header". Then, to actually get the logger, I need "src::severity_logger_mt< >& lg = my_logger::get();". I do not mind you do it the way you do it. However, I insist that "my" way is very incremental. I can start the most basic: boost::log() << "Hello"; and then incorporate streams, filters, formatters, etc. when the need arises. I do not have the feeling you do "just that". IMHO the incremental deployment nature is extremely important for a logging library. Probably your library can do all that. What I feel is that the user's exposure to the library complexity might be looked at. V.