Re: [boost] [log] Boost.Log formal review

Subject: Re: [boost] [log] Boost.Log formal review
From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2010-03-12 17:48:02

On 12 March 2010 09:00, Roland Bock <rbock_at_[hidden]> wrote:

> Barend Gehrels wrote:
>
>> 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 to
>> log.
>>
>> 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
>> library)
>> 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
>> this.
>>
>> 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.
>>
>
>
I think that any reasonable log library must be compiled to it's own lib due
to the intermodule singleton requirement. If some developers here think it's
not an important feature or that programmers are better off without separate
modules, please consider that users of your generic libraries may not be in
the more trivial scenario with only one statically built .exe.

/ christian