Then I will write a brief summary of my point of view. First, I think boost.log is by far the best logging system I've used, simply because it don't impose anything on the way I want the logging to be setup. I have one project in development using it (I will use it soon in another project which is open source). It's a game, multi-threaded (using tbb and boost), multi-process (client/server even with one computer solo game). It's composed of a lot of dlls, one hosting basic system code, like logging. Note that so far I only compiled both my projects and boost.log on Visual Studio 2010 and 2012 (my project only compile with 2012). I intend to try with clang and gcc but will not be able to work on this for several months. In this project I simplified the use of logs a lot, so I don't really use channels and other filtering features. However, I do use heavy/complex formatting and multiple sinks (vs console, console, files) with different formatting. In my setup I have only one cpp file using boost.log, which have a logging function called by other external code ( a bit like the setup I've pushed into cpp-netlib: https://github.com/cpp-netlib/cpp-netlib/tree/master/logging/src ). The main reason was that when you have multiple dlls, you should link them all to one boost.log dll. I compile all boost as static libraries and didn't want to make an exception so I just used boost.log in one only dll which is used by other dlls. As I don't need boost.log in my interfaces, I can do that, but others would be forced to link all dlls to boost.log dlls if they use boost.log in their interfaces OR if they use it in headers. I'm explaining all that so that you understand that I'm not in a common setup, I have only one cpp using boost.log and configuring logging exactly it the way I want. This mean that I have no idea on the compilation performance of boost.log as I compile it only once for all the project. On the run-time performance, yesterday I removed totally the logging code and run the game again. I didn't see a difference. I'm using synced sinks for now, I don't think the asyncs would help (other than delaying the logs in the console). However, I didn't measure anything AND I am too early in the development of this game to have reached any visible bottleneck. Which means that apparently boost.log don't seem to impact my game's performance, but it's too early to be totally sure. I think there will not be more problem than any other logging library on the performance side, and if there is, it's really easy to tweak it. Note that in my context, logs are coming from a lot of different threads and simultaneously, so it don't seem to be a problem for boost.log. Configuring the logging system so that I get exactly what I want is not always easy/obvious, both because there is a lot of options and because of some syntax tricks (boost.parameter usage example) which help once you know them but are obscure when you don't. Obviously, reading most of the documentation clarify things a lot, but I fear that people not taking logging seriously and just wanting a log file out will not read more than a few page. This is, I guess, expected so it's not a real problem. Boost.Log seem to allow all setups I've seen so far in different projects in widely different companies with widely different kind of software which make me wish boost.log was part of the c++ standard. I also wish the syntax to setup the configuration wasn't so verbose, but I don't see any way to reduce it, and it's easy to isolate. Most of the issues I had were in v1 but they were not critical. Some were actually specific to the VC compilers and not specific to boost.log. I switched to V2 recently and seen no change other than the one I pointed in the previous thread (which are not big problems). About the core being a singleton instead of function interface, I think that's the right choice as I've been confronted to the case where terminate() is called and I need to log something before quitting. I don't remember all the details but the problem I had was that there were chances that the boost.log core was deleted at the point I wanted to log before exiting. To solve this, just taking a shared pointer to the core at the being in a system that I guaranteed to be alive until the end solved the problem. I think that's the kind of situation Andrey was talking about to justify the core to be an object instead of a set of functions. I used boost log in some basic test projects and the availability of the trivial logging was really helpful. One thing I'd like to see in the future is to have some helper code to setup multi-process logging. Basically, I think (using asio) a log_client sink and a log_server logger would be helpful. The first one would automatically convert a log_record to something that can be sent (in a cross-platform way) to the network and assume it will be received by an application keeping a log_server object which would receive this log_record, then push it in it's own boost.log core. Users can already do this themselves, but I think if it would be helpful to have such tools in a (certainly not soon) future ready in the library distribution, like the other helper functions provided. As it would involve boost.asio (in my case I use another network library) AND a specific log_record serialization (maybe I prefer a specific binary format), I think providing this solution would be helpful, like most boost.log helpers, but also a basic example to setup more specific or complex setup for multi-process logging. The helper functions helped me sometime understand how some setups were done. But really I don't assume such feature would be provided in the near future, so that's just a suggestion. I didn't check the binary size cost, with this project I don't really care. The current size of the binary using boost.log is 690kb and it include a lot of code. I think I've said it all, I can't wait for boost.log to be finally in a boost release! Joel Lamotte