From: Geoff Leyland (gley001_at_[hidden])
Date: 2004-03-22 04:00:22
On 22/03/2004, at 6:37 PM, John Torjo wrote:
> Geoff Leyland wrote:
>
>> Hi,
>>
>> Why not do something like
>>
>> my_log("this_module_logging_flag_notes") << "Doing something in
>> this_module";
>> my_log("that_module_logging_flag_errors") << "Something went wrong in
>> that_module";
>>
>> where a log object is either (depending on a compile time setting) a
>> proxy for a stream or a not_logger than has
>>
>
> this is not such a hard thing to do ;) I've implemented some log
> classes like this in the (far) past ;)
> But what you would actually want is an enumerator or something, so
> that you can write things like:
>
> log<error>() << "some error";
> log<activity>() << "some activity";
That's not a bad idea!
I tend to work with the idea that either I want no logging at all, with
no code generated, or that logging is built in and I'm prepared to take
quite a hit for its overhead. I like using strings for keys because
I'm too disorganised to get all the enums I need in one place in a
large project.
However I think in a lot of cases, string keys would be to heavy for
the run-time decision "log or not", which needs to be quick, even if
you're generating the (large) stream code.
Perhaps a log with a policy for setting how to decide whether to be on
or off?
I have vague mis-memories of X "atoms" which might have been something
like
void large_function(void)
{
unsigned activity_log(get_log_index("my_activity"));
...
log(activity_index) << "blah";
...
}
Which means you get the indexes organised at run-time, but only suffer
the map search once per file/module/dll or whatever.
cheers,
Geoff