Subject: Re: [boost] [log] Boost.Log formal review
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-13 10:38:00
On 03/12/2010 01:00 PM, Barend Gehrels wrote:
> However, what might happen is that if there is an attractive logging
> library, Boost library writers start to use it, of course. All libraries
> using the logging functionality will need compilation. I normally use
> only header only libraries from Boost (sometimes making an exception).
> So this scenario might cause me stopping using Boost... There are much
> more people using only header-only Boost headers.
I think, you're exaggerating things. I agree that linking with a library
is a bit more complicated than including a header, but it's hardly a
showstopper. If it is, you should really revise your build system, and
it's not Boost's concern, IMHO.
> It might be even worse. If *existing* libraries will start using
> Boost.Log in an update (because it is really useful), existing project
> files and solutions will be broken.
> And finally for me the worst case scenario: if *existing *libraries
> *used in Boost.Geometry* will start using Boost.Log in an update, our
> Boost.Geometry library is broken and not header only anymore.
If you're speaking of libraries in the broader meaning than Boost, then
I see no problem in using Boost.Log in them. In fact, I think Boost.Log
is suited quite well for this scenario. That actually is also true for
the compiled libraries in Boost.
As for header-only libraries, I think, the most reasonable solution
would be to provide a configuration option for these libraries, so that
the user is able to decide, whether he wants logging or not. After all,
if the user already employs Boost.Log in his application, there's no
downside if headers of Boost libraries also use Boost.Log to provide
more information. If the user strives for header-onlyness, he would be
able to remove references to Boost.Log.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk