Using glog's design for Phobos?
Pelle
pelle.mansson at gmail.com
Fri Aug 27 08:41:26 PDT 2010
On 08/27/2010 03:49 PM, Steven Schveighoffer wrote:
> On Thu, 26 Aug 2010 18:19:24 -0400, Tomek Sowiński <just at ask.me> wrote:
>
>> Dnia 26-08-2010 o 05:59:19 Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> napisał(a):
>>
>>> At my workplace we're using Google's logging library glog
>>> (http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the
>>> more I use it, the more I like it. It's simple, to the point, and
>>> effective.
>>>
>>> I was thinking it would be great to adapt a similar design into
>>> Phobos. There will be differences such as use of regular argument
>>> lists instead of << etc., but the spirit will be similar. What do you
>>> think?
>>
>> Hm.. why not. Some quick thoughts:
>>
>> * Only a subset of features needs to be ported, e.g.
>> DLOG(...) == version(debug) LOG(...)
>> CHECK == enforce()
>> Also, I don't get the superlativeness of LOG_IF(INFO, pred) << ...
>> versus if (pred) LOG(INFO) << ...
>
> I think I know why, without even looking at the code. A typical issue
> with logging is that you want to evaluate the log output level, which is
> always an O(1) operation, before evaluating any other items which may be
> expensive, such as a custom predicate or message.
>
> i.e. LOG_IF probably does this:
>
> if(log.level >= INFO && pred)
>
> This is one of the only reasons I think we need a macro system. Mixins
> can do this, but who wants to always write mixin when doing logging?
>
> lazy is traditionally used, but it has costs as well. The best solution
> is to have a macro that converts:
>
> log.info(msg);
>
> directly into:
>
> if(log.level >= info) log.output(msg);
>
> which doesn't require lazy and is exactly what you *should* write.
>
>> * Instead of LOG(INFO, msg), please go for Log.info(msg).
>
> Most likely, this is due to the same thing.
>
> -Steve
Since lazy is rarely needed, one could use non-lazy by default and have
a lazy as well, like log.info.lazy(msg) or equivalent.
More information about the Digitalmars-d
mailing list