Re: [boost] thoughts on logging library

From: Andrey Semashev (andysem_at_[hidden])
Date: 2008-04-09 15:11:11

Christian Holmquist wrote:
> On 08/04/2008, Andrey Semashev <andysem_at_[hidden]> wrote:
>>
>> Although it looks very tempting, I have two concerns about it:
>>  1. Such configuration macros tend to introduce ODR violations. This
>>  problem probably won't get in the way in scope of a single executable,
>>  but what if the application consists of a dozen of them? It gets worse
>>  in case if the Boost library is compiled into binary itself.
> 
> I don't think there should be any ODR violations with header only libraries?
> Each executable (we're talking shared objects/libraries here, right?)
> may use boost libraries independently with different configs, as long
> as additional data members are not introduced to allow logging.

No, that is not correct. There are platforms (at least Linux is the one 
I know of) where ODR is required across module boundaries. If you have 
one definition of function foo in module A and another definition in 
module B, it is generally not defined which foo you'll end up using in 
executable C which links against A and B _and_ in both modules A and B. 
The point is, all the three modules will be using the same (one of the 
two) definition of foo.

There are means to change this behavior but it either means changing foo 
definition in a non-portable way or changing compiler settings, which 
will influence other things in a bad way. I would really hate to resort 
to solutions like this.

> The
> logging facility should IMO be a shared global entry for the
> executable to avoid such problems.

Not necessarily. I'd opt for both global and object-like logging entry.

> I think it'd be a reasonable
> requirement that library A-with-log.dll/so is binary compatible with
> A-without-log.dll/so.

I'm afraid, this will only be possible if the library interface 
(everything in headers, that is) does not depend on logging in any way. 
And that makes these configuration macros in user code or compiler 
settings useless. The library would have to compile either with or 
without logging support.

> As I wrote in my review a logging mechanism becomes a part of a
> library's public interface one way or another, so totally ignoring how
> that interaction behaves across library/executable borders seems like
> giving most of the burden to the end user.

In most cases modularity does not introduce problems with logging. And 
the problems that can be introduced (such as ODR violations or 
loading/unloading modules in run time) cannot be solved in scope of the 
logging library itself.

>>  > Is this along the line what boost.log has in mind, or will it be a
>>  > logging library not to be used by the boost libraries themselves?
>>
>>
>> I think, making Boost libraries able to write logs is definitely worth
>>  thinking of, although it may not be the top priority feature. IMO, we
>>  should first provide users with ability to easily write logs. We can add
>>  logging to boost libraries at a later stage.
> 
> If boost doesn't use its own logging library because that library
> doesn't address the more difficult tasks, why should it match the any
> other usage? IMO one could build sufficiently with boost signals,
> function and possibly bind... (simple code just tested with msvc 8..)

[snip]

Such code doesn't solve the problems I've pointed out. Although it 
solves the simple case, it won't provide things like flexible filtering 
  and attributes. You'll have problems with log initialization and 
multi-module applications. Thread safety is another issue. If you try to 
develop this solution to a product state, you'll end up with a 
full-fledged logging library, pretty similar to the many out there. :)

IMHO, whether boost uses its own library or not is irrelevant to the 
library usability for end users.