Boost logo

Boost :

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


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at