[logging] Review of proposed logging library
possibility to use printf syntax when logging [NOK OK]
Agree.
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. 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). Tom Brinkman
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).
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).
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). -- Martin Bonner Senior Software Engineer/Team Leader PI SHURLOK LTD Telephone: +44 1223 441434 / 203894 (direct) Fax: +44 1223 203999 Email: martin.bonner@pi-shurlok.com www.pi-shurlok.com disclaimer
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.)
Exactly ;)
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. Best, John -- http://John.Torjo.com -- C++ expert http://blog.torjo.com ... call me only if you want things done right
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Tom Brinkman Sent: Tuesday, February 12, 2008 8:45 AM To: boost@lists.boost.org Subject: [boost] [logging] Review of proposed logging library
possibility to use printf syntax when logging [NOK OK]
Agree.
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. 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).
With respect, I'm not sure there is *always* a better way than macros. For some applications macros provide a unique level of flexibility and efficiency. I'm the last person to advocate them, but when I constructed a logging library for our real-time scientific application, I was somewhat surprised to eventually figure out that logging macros *did* provide the best solution. So let's not discount John's effort on the grounds of anti-macro dogma alone, I'm sure we can find other problems ;).
participants (4)
-
John Torjo -
Martin Bonner -
Terence Wilson -
Tom Brinkman