Subject: Re: [boost] [log] Boost.Log formal review
From: Barend Gehrels (barend_at_[hidden])
Date: 2010-03-12 09:27:08
Roland Bock wrote:
> Stewart, Robert wrote:
>> It is theoretical as we don't yet know what any Boost library (or
>> other generic library) might wish to log. Barend raised the issue,
>> presumably because he was interested in logging from his library. I
>> know that we log a good deal from our internal libraries, but they
>> aren't libraries like those in Boost. What would prove unacceptable
>> is for each Boost library wishing to log something to create its own
>> API for doing so, unless the number of such libraries is close to one.
> I certainly agree that IF any boost library would want to log, we
> should discuss in which way to do it. It is just that I fail to see
> which one would actually want that.
Yes, it is because I'm interested in logging from our library.
I'm writing libraries since many years and always log, or have the need
But I'm not the only one.
Accepted Boost libraries:
Look e.g. in Boost.Geometry and you will find many places (this is our
Look e.g. in Boost.Polygon and you will find 15 files writing to
std::cout (= need to log)
Long time Boost Libraries in Trunk:
Boost.DateTime: 6 files writing to std::cout
Boost.Math: writing to std::cout (#ifdef BOOST_INSTRUMENT)
Boost.Spirit: has file debug.hpp
I didn't look in more of the sandbox but I'm sure there is more need for
Therefore I advocate a (as Rob states it nicely) *lightweight* logging
utility and I had hoped that Boost.Log would fulfil this need. If it
does not, it does not mean that Boost.Log is not good or not useful, of
course. And maybe I would use it for my own programs. But it is not the
library I'm looking for as a library writer.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk