I didn't think I'd have enough time to give this lib the attention it deserves, but as it turns out I've become sufficiently frustrated trying to use it that it has made reviewing easier... The library provides a good set of sinks out of the box, and it is relatively easy to add more. The interface used to actually log through is ok but it would be nice to make it easier to tailor to specific requirements. Given that filters have to expect that they will receive records from any/all components of an application that use boost log they need to: 1) very efficient 2) not fail (especially not throw) when expected attributes are not present or (where this is possible) attributes are not of the expected type/format. The latter aspect I comment on more below. I don't believe that the library achieves either of these. In addition the decision to avoid the coupling that would be required if exact attribute types were shared between the producer of the record and the filters seems reasonable - but it uglifies and complicates attribute access. In practice I don't believe it is required (there is no logging example or library provided attribute where knowledge of the type is not, in practice required/shared). It is however, clearly necessary that the actual set of attributes not be required and that attributes / types not known to the filters should be able to be ignored by the filters. I don't think these constraints should be too hard to meet while addressing 1 and 2 above and improving attribute access. If attribute access was simpler I wouldn't really care about the filter "lambda" or the formatting facilities as there would be no reason to use any logging specific facilities for these purposes. This would be an improvement as it avoids introducing yet another domain specific idiom into user code. Given the library scope there needs to be far more documentation, but I would rather see a smaller library that uses other libraries and established idioms (by which I do not mean printf :) instead of (re)inventing them. This comment is primarily directed at the filtering and formatting facilities, and the main barrier to removal of the existing facilities is the attribute access "quirks". I would really like to see mechanism where an enabling filter can be applied to loggers based on one or more constant valued attributes such that if the filter does not match the cost of invoking the non-matching loggers is very low. I've read the docs and some of the implementation. I've complied the lib and run a examples using gcc 4.3 As others have noted compilation speed is not a great feature of this library. It is a utility library and several users have said that they find it to be useful. However it isn't usable for me for some important use cases (the efficiency of "disabled" logs issue). I'm also concerned that this exact issue, as well as some of the filtering and formatting issues, would become even more significant and apply to many uses of the library if logging via this library was to become pervasive/the norm in widely used libraries (ie if in an application using a number of libraries the logging for all of them was handled via boost log). For these reasons I vote against the inclusion of the library in boost. I thought about making this a conditional yes based on addressing some of the above - but as this would mean removing some and radically changing other parts of the interface of the library this doesn't seem like a workable approach. Darryl