-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of James Fowler Maksym Motornyy wrote:

...

During development of last product I was missing good C++ logging library like one available in Java. I had to write it myself. Does somebody think that it will be useful to have it in Boost? Or there is such one in development?

Several projects related to logging have been mentioned recently (see message below). I'm about to throw another in the ring which could be used for primitive logging, although it's primary focus lies elsewhere.

[James Fowler Writes:]

The basic concept of logging is simple enough, but the wide range of useful implementation variations makes it really hard to envision a solid "one-size-fits-all" system. It may make sense to start working on a common set of patterns for a logging system interface, which could be used to consistently encapsulate many different implementations. This same issue came up in a discussion with Brian Baatz on profiling. Developing such an interface should be challenging enough, even without specifying implementation, but it's a more manageable first step. It also seems like a good way to foster cooperation among the various projects while allowing a healthy level of diversity, ideally improving the consistency over time for "early-adopters" of specific projects. [Brian Braatz Writes:]

(Thank you James for remembering I was working on this :) ) Sorry guys, have been OFF LIST for awhile here. Was busy integrating profiling into a very large application. I am working towards getting a status report out to this list here (hopefully) within this week. This will include What I added to the profiler What production tests we did What was learned by doing that Next steps for proposed boost.profile What I have learned in this process: Profiling EVENTS and LOGGING those events together is what is necessary to get the whole picture "Programmer" level logging is different from profile event logging What I see the Logging Library doing is connecting the dots with programmer supplied information Logging events and connecting them (mentally) with the profile report fills in the missing blanks for the developer for performance centered thinking Logging programmer detailed messages is more for finding bugs Logging events relative to the profiler, is more for performance related analysis What is also interesting, while I have not done a detailed review of the logging library, we seem to have done some things similarly. (there is about 5-10% overlap) Again, what profiling \ event tracing is trying to do is different I think than what the Logging Library is trying to do, there is some overlap. My State: I have integrated the profiler and things I have added to the profiler into our application In doing so, the library on top of that is using our internal (not boost) libraries for support My next step here is to take what I learned from doing this and combine them into one library that is boostified Additionally, I need to (this week) keep everyone in the loop by submitting a report.