PHWinfo - Afficher un message - Re: Boost Logging Lib, v2

17/10/2007, 01h11

On Oct 15, 4:24 am, "B.C." <b...@y.com> wrote:
> > IMO, the age of 'boosted' libraries is gone. A library may be
> > configurable in some way as long as it provides reasonable defaults
> > ('convention over configuration'). But configuration via policy
> > template parameters introduces high, unnecessary complexity that
> > hardly any real-world user is willing to accept.
>
> I don't know if the age of 'boosted' libraries is gone, but I ditto the fact
> that 'configuration via policy template parameters introduces high,
> unnecessary complexity'. At least for the two logging libraries, torjo and
> toast.

I think that policy based design is something that most programmers
are unfortunately not familiar with. I don't think it's hard to
understand though. It just takes that initial effort. And it's not
that much, I mean imagine C programmers learning OOP, that's -real-
effort, nothing like that kind of effort is required to understand
PBD. And once you do, I think that the interface to toast::logger is
actually very simple considering the power it gives the user.
Completely configurable at compile time for ultimate performance and
flexibility. I can give you the same amount of flexibility the old
fashioned way and no one would complain about the complexity (even
though it's almost exactly the same amount, just implemented
traditionally through runtime dispatching instead of compile time
dispatching). Unfortunately that traditional method is too slow for
some of our apps, and instead their authors resorted to hand coding
tight logging. My library was the direct result of not wanting
inconsistent hand coded interfaces all over the place in my companies
code.

> Using your libraries:
> - Can you change the logging levels at runtime without having to recompile
> the application?
> - Can you switch the logging levels only for specific classes, also at
> runtime without having to recompile the application?
> - the ultimate question, are your libraries at least as simple to use as
> log4j even if we are talking about c++?
>

The problem with toast::log is that you can do anything you want.
Thus it's impossible to document all the possibilities. The answer to
your first two questions is yes. I've personally never used log4j, or
log4cpp, but so far the only feedback I've received (after the first
step of understanding PBD) is that it's remarkably simple to use.

> The examples in the Toast library are slightly better, but still bare bones,
> and they raise questions rather than showing what you can actually do. I
> didn't try log4cpp, but I was surely surprised when it was mentioned on one
> of your pages that it was not fast enough. Well, I believe you. I didn't
> have any performance problem with log4j (I assume log4j is slower than
> log4cpp), but my requirements for speed were not as severe as in your case.

I would greatly appreciate it if you asked me the questions raised

I'd be happy to write more examples. If your performance requirements
aren't high, you may very well be happy with log4cpp. I hope though
that any logger that makes it into boost serves all markets and not
just the ones where performance isn't a concern.

Neal

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

17/10/2007, 01h11	#4
Neal E. Coombes Messages: n/a Hébergeur:	Re: Boost Logging Lib, v2 - added documentation On Oct 15, 4:24 am, "B.C." <b...@y.com> wrote: > > IMO, the age of 'boosted' libraries is gone. A library may be > > configurable in some way as long as it provides reasonable defaults > > ('convention over configuration'). But configuration via policy > > template parameters introduces high, unnecessary complexity that > > hardly any real-world user is willing to accept. > > I don't know if the age of 'boosted' libraries is gone, but I ditto the fact > that 'configuration via policy template parameters introduces high, > unnecessary complexity'. At least for the two logging libraries, torjo and > toast. I think that policy based design is something that most programmers are unfortunately not familiar with. I don't think it's hard to understand though. It just takes that initial effort. And it's not that much, I mean imagine C programmers learning OOP, that's -real- effort, nothing like that kind of effort is required to understand PBD. And once you do, I think that the interface to toast::logger is actually very simple considering the power it gives the user. Completely configurable at compile time for ultimate performance and flexibility. I can give you the same amount of flexibility the old fashioned way and no one would complain about the complexity (even though it's almost exactly the same amount, just implemented traditionally through runtime dispatching instead of compile time dispatching). Unfortunately that traditional method is too slow for some of our apps, and instead their authors resorted to hand coding tight logging. My library was the direct result of not wanting inconsistent hand coded interfaces all over the place in my companies code. > Using your libraries: > - Can you change the logging levels at runtime without having to recompile > the application? > - Can you switch the logging levels only for specific classes, also at > runtime without having to recompile the application? > - the ultimate question, are your libraries at least as simple to use as > log4j even if we are talking about c++? > The problem with toast::log is that you can do anything you want. Thus it's impossible to document all the possibilities. The answer to your first two questions is yes. I've personally never used log4j, or log4cpp, but so far the only feedback I've received (after the first step of understanding PBD) is that it's remarkably simple to use. > The examples in the Toast library are slightly better, but still bare bones, > and they raise questions rather than showing what you can actually do. I > didn't try log4cpp, but I was surely surprised when it was mentioned on one > of your pages that it was not fast enough. Well, I believe you. I didn't > have any performance problem with log4j (I assume log4j is slower than > log4cpp), but my requirements for speed were not as severe as in your case. I would greatly appreciate it if you asked me the questions raised I'd be happy to write more examples. If your performance requirements aren't high, you may very well be happy with log4cpp. I hope though that any logger that makes it into boost serves all markets and not just the ones where performance isn't a concern. Neal -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]