From: Rene Rivera (grafik.list_at_[hidden])
Date: 2004-10-22 17:27:06
Jeff Garland wrote:
> Well, personally, I'd really like to try and go macro-less on the logging
> approach. I don't like macros because:
> 1) The logging code will be in the release build anyway (for all industrial
> apps I've seen this is the case).
Yes. The debug systems I've implemented or used all behave that way. My
preferred method is to make log output depend on whether the LOG
facility is available at runtime. That is if my log.dll/so is around or
not. That level of configuration by end users is very easy for them to
Also logging is used for output other than debug output in system
friendly programs. For example sending info when your server application
starts and stops to syslog.
> 2) Macro systems tend to be fragile -- pass it bad type (eg:string instead of
> char*) and it might crash your app. In this day and age the compiler should
> detect these errors...
And macro systems are much harder to make work flexibly. It's much
harder to change how a macro works than it is a function call without
also changing all the code that uses the macros.
> 3) I hate having to read macro code and then 'expand it mentally' -- I'm
> getting too dang old for it.
Aren't we all ;-)
> Because of #1 I'd actually be fine if all the macro did was enable/disable so
> I it's use would effectively be optional.
John's code is very close to that. If the code that his BOOST_LOG
produces could be reduced to a simpler public interface so that those of
us who don't want to use the macros can use instead, it would make it a
winner for me.
One important aspect of having a public macro-less interface, is that it
would allow those with current log facilities (like me) to recode
without changing all the logging calls. Which is a rather large task
when you have a few million lines of code in your application :-\
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk