Re: [boost] Debug/Stream Libraries?

From: David A. Greene (greened_at_[hidden])
Date: 2001-11-26 16:28:56

Jesse Jones wrote:

>>> Not true. Instead of providing an overloaded operator<< you can
>>> provide an overloaded ToStr. About the only real difference is that
>>> the ToStr functions can take optional arguments so you don't have to
>>> use that godawful manipulator stuff to modify the formatting.
>>>
>>But printf-like format strings are a big source of bugs.
> 
> Yep, but that's not a problem with ToStr. Consider this code:
> 
> template <typename A1, typename A2>
> inline void LOG(const char* c, const A1& a1, const A2& a2)
> {LOG(c, ToStr(a1) + ToStr(a2));}
> 
> This is fully as type safe and customizable as  iostreams...

Ok, I don't understand then what you mean by "take optional
arguments...to modify the formatting."  What formatting are you
modifying?

>>anything that advanced yet.  :)  I'm curious -- how do you get
>>line number information?  Do you have to pass __LINE__ to the
>>function?  I've always hated the fact that we can't make template
>>functions "inline-aware" and have __LINE__/__FILE__ reflect the
>>line number where the template is inlined and not the line number
>>of the template source file (yeah, yeah, stupid preprocessor...).
> 
> There's no support for line numbers. I haven't seen a need for 
> anything like that. 

I always thought it would be nice for my users to scream at me
and then tell me where the problem is.  :)  A unique ID for each
(static) message would be almost as good.

>>Oh, I know it is.  But the fact the everyone and their mother
>>does it seems to me to make a good case for a convenient library.
>>
>>Exactly _because_ it is simple makes a good case.
> 
> Maybe.

Perhaps it's not possible to make something flexible enough for
everyone.  I think it is, but then I haven't considered all of
the issues and most of the folks here have more experience
with professional/huge software projects than I do.  I dunno,
if a progress bar can make it into Boost, I'd think a logging/debug
library would be a slam dunk.  :)  That's not to take anything
away from timer, of course.  :)

>>Right, but how does LOG know which sink to send the message to?
>>
> 
> LOG sends the assembled string to every enabled sink.

Gotcha.  I like that messages can go to multiple sinks.

>> From your usage in the previous message, it looks like each
>>variable in the message is passed as a separate parameter.  Doesn't
>>that require a whole lot of overloaded methods?
> 
> Currently I support LOG functions with up to 10 custom arguments so I 
> have just over 10 overloaded functions. (Actually I have another 10 
> because there's a debug only version called TRACE).

This seems excessive to me.  It's certainly not scalable.  But maybe
log messages are short enough that it doesn't matter.

>>An enum would work almost as well, but as I said, I can't put my
>>finger on it.  I can't think of a terribly good argument _not_
>>to use a string.
> 
> I don't think so. The problem with an enum is that you have to define 
> all the categories up front. With a string you can link against the 
> UberLibrary and the logger (and perhaps a Log menu) will automagicly 
> become aware of the new "Uber" log category.

Good point.  It would be nice to be able to support plugins.
In that case an int is no better than a string and a string is
more flexible.  Still, if we can somehow detect category typos
it would eliminate one source of problems.

>>Of course the presents the (probably likely) chance that the programmer
>>will mis-type the category in some message and never see it (since he
>>doesn't know the name of the category to turn on).  Though inn a
>>GUI he will at least get some strange menu entries.  :)
> 
> Yep, and it is pretty obvious in a GUI app. In other apps I think 
> you'd still want to do something similar. For example, in the past 
> I've had app's that wrote the categories to an XML file on shutdown 
> and read from that file on startup. This way everyone on the team 
> could easily customize the logging output for the stuff they were 
> interested in. This isn't as in your face as a menu, but I think 
> misspelled categories would still be found fairly quickly.

You're probably right, but I'm a fail-fast kinda guy.  :)

                                    -Dave

-- 
"Some little people have music in them, but Fats, he was all music,
  and you know how big he was."  --  James P. Johnson