[Log] Alpha 1 preliminary announement
Hello, I've uploaded to the Vault an alpha version of the Boost.Log library I'm working on. It is available here: http://tinyurl.com/3cdg88 During the development I tried to follow the results of previous discussions in this list and requirements collected on the Wiki page: http://tinyurl.com/2fndfg At the current stage the library has a quite formed core implementation and a framework for developing leaf components quite ready for further extension with a few components implemented to play around. There is no official documentation for now, but there is a well-commented example/tutorial in the package, which is suitable to catch the feeling of the lib and may be used to play around with the code. The library builds in a thread-safe dll only for now. The HEAD of the boost repository and "thread_rewrite" branch of Boost.Thread library are required to build the lib. Support for other configurations will be added later. The purpose of this announcement is to collect feedback on the early development stage. Please feel free to suggest any architectural improvements and point out any bugs. Another thing I'd like to settle is a set of features that should be available in the library out of the box. In particular, a set of available sink types (for now only text ostream sink is implemented), loggers and attributes. It is my belief that the library should be proposed for review in a sensible minimal set of features and be extended later, but finding this set is not an easy task. Looking forward for your comments. Some side announcements, proposals and comments: - The "thread_rewrite" branch of Boost.Thread does not yet support read_write_mutex, which is used by the Boost.Log. There is a reduced implementation of it for pthreads. I'll be happy if someone from the Boost.Thread development take it as a start to implement the final implementation of the R/W mutex for pthreads. - There is an empty_deleter class in the library package. It is intended to be used with shared_ptr in cases when the pointed object should not be deleted by the pointer (for example, when it resides on the stack). Obviously, there is no point to allocate reference counting object and perform thread-safe reference counting when this deleter is provided. I propose to optimize shared_ptr with respect to this deleter type and elide allocations and ref-counting when it is provided in constructor or reset. - Please see boost/log/detail/type_info_wrapper.hpp. There is a std::type_info wrapper class that allows to copy, compare and order type information objects via usual operators and constructors. This allows to store type_info in containers, for example. Is it worth extracting as a separate component to the boost directory. - In the same file there is a BOOST_NO_UNSPECIFIED_BOOL macro definition, which I believe should be in Boost.Config. Maybe it should be moved there? -- Best regards, Andrey mailto:andysem@mail.ru
Hi Andrey, I would like to look at your library, but the URL
doesn't seem to work. The link to the wiki does ...
..., but the page doesn't seem to link to your code. Do you have an idea what the problem might be? Peter
Hello Peter,
I would like to look at your library, but the URL
doesn't seem to work.
Hm... It does for me. You may try to download it directly from the vault: http://www.boost-consulting.com/vault/ The file is BoostLog.zip in the root.
The link to the wiki does ...
...., but the page doesn't seem to link to your code. Do you have an idea what the problem might be?
There is no link to the file, these requirements were gathered before the implementation was published. Though it might be a good idea to add the link there. -- Best regards, Andrey mailto:andysem@mail.ru
Dear Andrey, dear all, I was wondering whether it would make sense to extend the log library to an exception framework. This, I believe, could be done with minimal effort. In my opinion every exception should lead to a log message, as an exception will usually represent the most extreme condition available in an application. One way of raising an exception is to stream the error messages to a sink, in the following way: int errorCode = 3; myExceptionType exc; exc << "An error occured: " << errorCode << raiseException; Within myExceptionType, "void raiseException(void)" triggers a "throw(*this)". The rest of the streaming functionality is already implemented in your library. Extending the log classes with this functionality could be done with just an "operator<<(void (*val)" (void))" and adding a "what()" member function. This would allow the simultaneous use of the log classes as an exception framework. Error messages would automatically end up in the log files specified by the user, and log-related clean-up (closing of log-files, connections, ...) could be handled as part of the process of raising an exception. Not sure whether this is a pipe dream, hence no entry in the Wiki. Best Regards (and have a nice Sunday evening), Ruediger Berlich
Hello Ruediger, Sunday, May 20, 2007, 11:21:30 PM, you wrote:
Dear Andrey, dear all,
I was wondering whether it would make sense to extend the log library to an exception framework. This, I believe, could be done with minimal effort.
In my opinion every exception should lead to a log message, as an exception will usually represent the most extreme condition available in an application.
Although I don't quite agree with part "_every_ exception should lead to a log message", I think exception loggability is a good thing.
One way of raising an exception is to stream the error messages to a sink, in the following way:
int errorCode = 3; myExceptionType exc; exc << "An error occured: " << errorCode << raiseException;
[snip] I'm not sure I understood your suggestion correctly, are you saying there's a logger inside myExceptionType that collects the error message? What message is available in the thrown exception object then? You see, logging record may not make it to the log and, actually, may not even get formatted, while the exception, obviously, has to have a valid error description inside anyway. It's easier to compose the exception first and then put it to log. I see it as a convenient macro like this: #define BOOST_LOG_THROW(logger, svty, exception_type, strm)\ if (true) {\ exception_type e;\ wrap(e) << strm;\ BOOST_LOG_SEV(logger, svty)\ << "Exception occurred at "\ << __FILE__ << ':' << __LINE__\ << ". " << e;\ throw e;\ } else ((void)0) BOOST_LOG_THROW(lg, minor, std::runtime_error, "CPU not found"); BOOST_LOG_THROW(lg, major, std::invalid_argument, "The argument X has invalid value " << X); BOOST_LOG_THROW(lg, fatal, boost::exception, "I'm dying, here's my dump: " << dump); (I'm not familiar with Boost.Exception, does it have an ability of such message formatting?) While this looks a quite nice addition to the library, I'm afraid final users will most likely want to extend or modify the BOOST_LOG_THROW above to suit better their needs (i.e. to add a specific tag to such messages or to put them into a separate channel), and I don't see the way to do it. Although I'll add it to the Wiki page since it fits well for simple use cases. Thanks for the suggestion! -- Best regards, Andrey mailto:andysem@mail.ru
participants (3)
-
Andrey Semashev -
Peter Simons -
Ruediger Berlich