Re: [boost] Boost Logging library - first draft

From: JD (jean.daniel.michaud_at_[hidden])
Date: 2007-04-01 04:52:57

> Externally defined formatting objects are employed to manage
> the actual presentation.
> 
> I personally feel that macros should be avoided as much
> as possible. One argument for using macros is the ability
> to conditionally include or exclude the logging code at
> compile time.
> 
> However this view is usually a product of 'developer centric'
> thinking and misses the much more important 'user centric'
> aspects of logging. The fact is that there are an awful lot
> of reasons to add logging information to a piece of software
> other than debugging. It is often desirable to be able to
> monitor the ongoing state of any medium to large sized application
> so this activity is not solely for the benefit of the developer.
> 
> On top of this, the number of places in a piece of software
> where performance is critical is often quite low. For really
> critical sections of code then of course a compile time defined
> macro could be appropriate. However I feel that in the many
> cases logging should be considered an integral part of the
> software being developed and so to be available in the
> production hardened release.
> 

This has been briefly discussed in the past.

Caleb Epstein:
* Messages which won't be logged shouldn't even go through the
formatting step.  I'm pretty sure this cannot be done in a single call
w/o macros though.

Rene Riviera:
It's possible without macros for some compilers using careful template
instantiation.

Darren cook:
I like this idea. E.g. from Caleb's next mail:
      BOOST_LOG (log_name) << the << things << to << output;
      BOOST_LOGD (log_name, the << things << to << output);

Daniel Frey:
OK, although there is more to keep in mind. In our logging system, we
also added a try/catch macro around the expression that is to be logged.
The reason is, that we never want a log-message to abort the program.

For me, macro are fine. In the logging case, it allows you to log 
anywhere in your code without any overhead (no need to declare extern 
global macro) moreover the logger instance is hidden in the library 
internal. I think it enhance code readability (in the case of a logging 
library!). Then, it avoid user to deal with the log manager 
instantiation. At first, I though it was a flaw in the library but I 
tend to think that as a feature now :)
Again, _simplicity_ is really what should be aimed at.

> The current version of my logger is hosted on sourceforge.net
> at http://sourceforge.net/projects/logplusplus/
> 
> Right now it is undergoing some major revision to separate out
> what really is core logger activity and what is 'optional extras'.
> When that is complete I will likely place it in the sandbox for
> interested people to assess.
> 
> Jean, I will be looking over your contribution soon to see what
> common ground our loggers share and if there might be a possibility
> of some 'cross pollination' of ideas.
>  

My point is not really to deliver a library, but more to start the 
discussion over and agree on a minimum set of requirements. I'm not sure 
this can be done actually... :) What you could you anyway, is to 
"boostify" your library and try to submit it (doc, test, bjam, etc...). 
See http://www.boost.org/more/lib_guide.htm and 
http://www.boost.org/more/submission_process.htm.

JD