Boost logo

Boost :

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 modify the formatting." What formatting are you

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


"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