[Box Backup-dev] Logging

[Charles Lecklider]

Ben Summers wrote:
> 
> On 25 Dec 2005, at 19:09, Charles Lecklider wrote:
> 
>> Chris Wilson wrote:
>> <lots of stuff about logging I only just read properly>
>>
>>> * All TRACE calls are changed to Log::Log(Log::TRACE, ...)
>>
>>
>> How are you going to get those to compile out for a release build? The
>> nice thing about TRACE macros is that they can be removed  completely by
>> the compiler, and I think it's important to do that for a release  build.
>>
>> Short of wrapping every Log::TRACE call in #ifndef NDEBUG//#endif I
>> don't see how you can do the same thing with the new system. Perhaps
>> there's some clever C++ trick I don't know about?
> 
> 
> There isn't. The best way is to modify the existing macros to use the 
> underlying logging system, and still compile them out in release  builds
> (unless the user has configured them to stay in.)

Oh. Other than the joyous OO nature of a load of static calls, I'm not
sure I see the point of a class then.... No matter - I'm not writing
this bit, so as long as TRACE can be compiled out in the end I don't mind.

> Using streams for generating the log messages will of course always 
> construct the argument before logging, even if it's discarded by the 
> call. I suspect this won't be too much of a problem, except on low 
> powered embedded systems. I would quite like this to be able to fit 
> into the hacked firmware of those consumer network connected hard  discs
> and work acceptably on that low powered CPU.

That sounds like a big step backwards to me. I'm all for having a
cleaner shinier OO logging interface, but only if *all* the TRACE can go
away for release - unnecessary memcpy()'s on a VIA C3 quickly get expensive.

-C