Hello JD, Sunday, April 1, 2007, 12:47:04 AM, you wrote:
Hello,
So here is the question: "Is there any interest in a logging library for boost?"
John Torjo did not answer my mail, beside I looked at pantheios. it seems a little bit complex... My idea is that a logging library should be _simple_ to use.
Here is a small example:
[snip]
You can find the first draft of a logging library in the boost Sandbox vault. It consists of a header files, some examples and documentation. Put the file at your boost root folder and unzip it.
It compiles with msvc and vc-8_0. I'll try with gcc asap.
So let me know if you think it worth something or not.
I've took a quick look at the implementation and the docs of the library. First, I'd like to thank you for performing this analysis of previous proposals attempts. You did a great job of summarizing all opinions and suggestions were made which helps to better understand the requirements to this kind of lib. Now to the point. I understand and agree that the logging library should be simple to use but I see no reason we should sacrifice the extensibility for it. To my mind a carefully designed library interface is the way to go, not the functionality and extensibility limitation. And unfortunately, I see little ways of extension of your implementation to get the functionality I got used to. I may be wrong and may have missed something. 1. The whole design looks more like a stream dispatcher rather than a logging library which has to be more complex. I see no scope logging support, no custom log record attributes, no filter or wide logging support, and I see no obvious way to implement these on the user side to plug them into your lib. The way to completely wipe out logging from the user code during compile time would be good too, though it's not very difficult to implement it. 2. The logger object is a singleton which, I think, would be inappropriate once I would have custom attributes. I think the logger should be separated from the core library, which indeed would be a singleton. This would not only make attributes possible, but form a "source" concept. A logger would be an implementation of this concept, though allowing other implementations of "sources" (like, a third-party application console interceptor, for example). 3. The "sink" (or "target") concept is simplified down to a stream, which is not a best choice. Remember that the log record is more than just a string. It consists of a number of parts (attributes) - record number, time, source code location, severity level, and (yet another attribute) message text. There may be other user- or library-defined attributes. And the "sink" should be able to define which attributes to log and how to format them. In fact, a "sink" may apply its own filters to wipe out the unneeded records from the output. This is not possible with a simple stream "sink". 4. The library is header-only, which will raise some problems in a complex applications that consist of more than one module. The logger instance will be visible only in one module, other modules will have their own loggers, which obviously mean problems with their initialization (which streams to add as "sinks"?). I believe that logging library should be implemented as a shared lib. 5. I think there are too many macros in the interface. I'd rather have BOOST_LOG as an inevitable minimum, but no more than that. If you are interested, I could describe my view of architecture of such logging library (I'm working on the implementation on an early stage). Though, I think, many of us already have such view in our minds and maybe have it implemented. And finally some implementation-regarded notes (though I understand this was just a draft, I couldn't hold myself, sorry :) ): 1. The logger is default-constructible from the user's code, but it seems that you intended to make it singleton. 2. logger::get_instance is not thread-safe - function-scope statics are used. 3. You should not define namespace bl = boost::logging; in the library code. 4. Element global operators should be in boost::logging namespace. They will be reachable via ADL. 5. Each logging record involves std::stringstream (even not ostringstream) construction, formatted output copying, and destruction. I'm afraid, that would be a performance impact on the application. 6. I believe, some of the "Logging typedefs declarations" might have been hidden into the logger class and renamed. Some other names (like null_deleter) might have been hidden to an internal namespace. PS: I hope I didn't kill your encouragement with my reply. This is the last thing I'd wanted to do. -- Best regards, Andrey mailto:andysem@mail.ru