Re: [boost] Debug/Stream Libraries?

From: David A. Greene (greened_at_[hidden])
Date: 2001-11-26 14:30:15

Jesse Jones wrote:

>>I find iostreams much too convenient
>>to just dismiss them out-of-hand.  Often I want to dump the
>>state of some object and iostreams is the only way to do it
>>nicely.
> 
> 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.  Plus
if I've already written operator<< for serializing purposes,
it would be nice to be able to re-use it (ToStr could simply
print to a stringstream, of course).

>>Here is where I find iostreams nice to use.  My simple debug
>>macro is used like this:
>>
>>DEBUG("Sent " << bytes << " bytes to " << address, <other_args>);
>>
>>where <other_args> includes categories, levels, etc.
> 
> That part is nice. My system relies on overloaded LOG functions that 
> each take a different number of arguments so I have trouble sticking 
> in optional arguments. Currently if the user wants to log something 
> and not use a category they have to pass in NULL or "" for the first 
> argument.

I don't use optional arguments, actually.  I haven't written
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...).

>>I haven't
>>implemented anything beyond a simple global debug level since
>>I didn't want to spend all my time writing debugging code.  This
>>is one of the reasons I asked whether Boost might provide such
>>facilities.  :)
>>
> 
> It's pretty darn easy to do this.

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.

>>How do you specify different sinks?
> 
> The Log singleton has an AddSink method. Normally in main the client 
> code will add a few of the provided sinks (or perhaps a custom sink). 
> Something like this:
> 
>     Log::Instance()->AddSink(new StdErrSink);

Right, but how does LOG know which sink to send the message to?
Are categories bound to sinks?  I can imagine many ways to do
this -- I'm curious about your particular implementation.

>> Is LOG a vararg macro?
> 
> Overloaded functions. Something like this:

Gotcha.  See my question on line numbers above.  :)

>     inline void LOG(const char* c, const std::string& s)
>     {Log::Instance()->Write(c, s.c_str());}
> 
>     template <typename A1>
>     inline void LOG(const char* c, const A1& a1)
>     {LOG(c, ToStr(a1));}
> 
>     template <typename A1, typename A2>
>     inline void LOG(const char* c, const A1& a1, const A2& a2)
>     {LOG(c, ToStr(a1) + ToStr(a2));}

 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?

>>I don't know why, but I feel a bit uncomfortable channelling
>>based on a string.

> I think it's way better than relying on a number. It gives you more 
> control about what gets streamed out and it fits in nicely with GUI 
> apps where you can stick the categories in a menu so that you can 
> toggle them on and off at runtime (and hopefully store the state away 
> in a pref as well).

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.

>>Maybe it's that the
>>compiler can't check whether a valid channel is being specified.
> 
> There's no such thing as an invalid category. When a new one is 
> encountered the category table is updated and the category starts out 
> disabled.

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.  :)

                             -Dave

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