The Boost list has been very active for the last few weeks. Some of the major topics are the new Boost.Log library, Boost’s participation in the Google Summer of Code program, and general problems with Boost development.
Logging
The logging library submitted by Andrey Semashev was accepted on Wednesday. The library is very flexible, allowing users to define arbitrary attributes to attach to log records and dispatch these logs records to any number of sinks. It provides a number of built in attributes and sinks, and contains tools for filtering log records and formatting them for each sink.
Here’s the simplest example from the documentation.
#include <boost/log/trivial.hpp> int main(int, char*[]) { BOOST_LOG_TRIVIAL(trace) << "A trace severity message"; BOOST_LOG_TRIVIAL(debug) << "A debug severity message"; BOOST_LOG_TRIVIAL(info) << "An informational severity message"; BOOST_LOG_TRIVIAL(warning) << "A warning severity message"; BOOST_LOG_TRIVIAL(error) << "An error severity message"; BOOST_LOG_TRIVIAL(fatal) << "A fatal severity message"; }
The library currently resides at http://boost-log.sourceforge.net/
Google Summer of Code
The time for applications for the Google Summer of Code program is coming up. There has been quite a bit of discussion about the potential projects.
- The perennial BigInt library is again a potential project. Although many people have worked on a Boost big int project in the past, including at least one GSOC project, none has ever reached review readiness.
- The elusive Phoenix v3 which was accepted a year and a half ago as the replacement for Boost.Lambda, pending a mini-review, has not yet been written. Phoenix v3 is a rewrite of Phoenix using Boost.Proto. Phoenix v2 currently lives under Boost.Spirit.
- The Process library originally written for SoC 2006, is still incomplete, despite several efforts over the past few years. One possible project would be to bring this library to the point where it would be ready for inclusion in Boost.
- For details about these projects and more, take a look at http://svn.boost.org/trac/boost/wiki/SoC2010.
What’s Wrong with Boost
We’ve been having another of the discussions that crop up every year or so about what’s wrong in general with Boost. A number of issues were raised, but probably the most common complaint was about unmaintained libraries. In fact, this particular issue spawned a separate thread about how we should deal with unmaintained libraries. The requirements state that it is the library author’s responsibility to find a new maintainer if he can no longer maintain the library, but this has not worked out in practice.
Am I the only one who thinks that 1MB+ download for the source code of a library that does nothing but logging is insane? It seems like attaching “Boost” to anything makes it glow if you are a C++ developer. The source code should be closer to 10K.
Without counting the documentation, the tests, the tools used to run the test, and of course all the Boost libraries used directly or indirectly by Boost.Log.
Anyway, I hope you will profit of the reduction and try one of the other free Boost libraries included on the package.
It would be nice if unmaintained libraries were marked “deprecated” on this list… http://www.boost.org/doc/libs
I think it’s natural that a big collection of libraries like boost will start to accumulate legacy code. Many of the libraries that exist now will probably fall out of use with the introduction of C++0x. A lot will probably be superseded by libraries that are built around C++0x features.
Is there a policy in place for deprecating and removing old libraries? I think giving developers a clear idea of how long a library will be available for is the best that can be done…
This is the main problem. A library is not considered as unmaintained until the authors states this explicitly. Fortunately, there are some Booster that are ready to maintain the unmaintained ones.
Just a small question – does it mean that Torjo’s logging library will have no way to get into Boost?
I am not an authority on the subject (is anyone though?) but I would think not. There has been discussions in the past about introducing similar libraries to functionality already present, and that has been shot down. The closest I have ever seen is signals2 replacing the signals library.
Torjo’s lib would probably have to supercede and force deprecation of the accepted library.
There’s no particular policy in that regard. We’ll just have to see what the community thinks. If Torjo’s library is significantly different in its strengths and weaknesses, we could end up with two logging libraries.