From: John Torjo (john.groups_at_[hidden])
Date: 2008-02-12 12:20:31
Martin Bonner wrote:
> From: Tom Brinkman
>>>> The use of macros will always be a
>>>> discussion point, but it is convenient for a
>>>> logging library. I do not have big issues with this.
>> I would like to see us push our selves harder here. This is
>> "boost" after all, whose developers and users, fret for hours
>> on the miniutia of the perfect interface. The logging library
>> is no different than other libraries. All of us have though
>> at one time or another having just this "one" macro wont make
>> that much of a difference. A little more exploration and
>> discussion of our interface goals always reveals
>> a better way.
> Counter example: BOOST_FOREACH
> (I'm fairly sure there are more).
Indeed so ;)
The thing about logging macros is this:
- assume we drop the declare/define macros
I can get to allow for this syntax:
if ( g_l() ) g_l().read() << whatever;
But , because there's a bit but :)
What if you want __LINE__,__FUNCTION__ to be logged, and you'd like this
to be transparent to the user?
Adding them manually each time you do logging, I think will be a pain.
About the rest of the macros, I think I can remove them.
> I also think that logging is another one of the cases where a macro is
> appropriate (I don't think there is any way to have a runtime argument
> completely disable execution of logging expressions without have an 'if'
> in there at the top level. That means either the user needs to write
> the if, or it has to be in a macro. I vote for the macro.)
>> Lets not settle. John is clearly motivatated
>> to create a great logging library that useful for all c++ developers.
>> Lets get behind this effort and help him get there between
>> this review and the next one (if there is one).
About the next review : I assume there will be one :)
> Here, here. I am very impressed at the way John has taken the criticism
> of his library (some of it expressed in fairly forthright terms), and
> seems entirely committed to a second significant rewrite and yet another
> go-round in the bear-pit (even before the review manager decides whether
> to accept or reject the library).
I can do better. I know my mistake was trading simplicity for
flexibility. Now I just need to find the right balance.
The harsh thing for me was the fact that most issues were told at the
review and not before. Before the review, privately, I only got positive
feedback, except for Amit's - and his feedback came in pretty late.
-- http://John.Torjo.com -- C++ expert http://blog.torjo.com ... call me only if you want things done right