> 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'. [...]
> I checked the examples in both and I must say my brain went a bit numb.
>

It just needs a bit of getting used to - just like anything new
>[..] there is much to learn from Java in the C++ world! It uses the
> concept of specialized loggers - you can log to files, to databases, to
> tcp/ip sockets, you can send emails etc (I guess a specialized logger maps

Yes, this is available with my lib as well - the concept of
"destinations".

> to your concept of policy). One of the greatest things about log4j is that
> you can configure the logging on the fly, at runtime, by changing the log4j
> configuration file, without having to change and recompile your application.

In fact if you wish, you can add that on top of my logging lib -
perhaps I'll do it later, if I have the time.

> You can assign names to loggers, and usually the names are complete class
> names including the package name. So, when I need logging in a class all I
> do is declare:
>
> class MyClass {
> private static final Logger log = Logger.getLogger(MyClass.class);
>
> public void myfunction()
> {
> log.debug("....");
> // or
> log.error("...")
> // and so on
> }

This is sooo twisted Why declare a logger in each of your class,
when you can use a global one?
Anyway, it's your program, you can do as you wish

> Using your libraries:
> - Can you change the logging levels at runtime without having to recompile
> the application?

What do you mean by that?

> - Can you switch the logging levels only for specific classes, also at
> runtime without having to recompile the application?

I really don't know why you'd want that kind of granularity (class
level), but I guess you could do it.

> - the ultimate question, are your libraries at least as simple to use as
> log4j even if we are talking about c++?

Well I know the docs need a bit of work ,and I'm working on that -
basically, I want to provide you with scenarios - and how you should
use the lib in each scenario.

>
> And now, some concrete critique:
> On this page,http://torjo.com/log2/index.html, the examples. Please note the
> titles:
>
> Example 1: you choose to use the L_(msg) sytax:
> Example 2: you choose to use the L_ << "some " << " cool " << "log message"
> syntax
> Example 3: you choose to use the same syntax as Example 2, but also use
> formatters and destinations.
> Example 4: you choose to use levels
>
> Your examples are driven by different syntaxes that can be employed to do
> the same thing which is what exactly?!

They all do logging - it's just that the usage syntax can be
different. And that is for you to decide - do you want to trade speed
for ease of use (in our case : speed : Example 1, ease of use :
Example 2)

>
> Your examples should show me how to use your library in the easiest and
> simplest manner to solve some logging problems that you think might occur in
> the real world. They don't have to be the most complicated examples, but you
> know, they should give me the taste of your library.
>
> IMO your examples should be something like this:
>
> Example 1: How to log to a file - here you can create 2, 3 classes that call
> each other and put some logging statements.

See test_simple_dump_to_cout.cpp - it simply dumps to cout.
See test_multiple_simple_logs.cpp - one log dumps to cout, one to
file, one to debug window

> Example 2: How to add logging to a file to an existing application - this is
> probably one of the most common patterns of usage of your library.
> Example 3. How to log in two different files. Here you have: class A logs to
> file1, class B logs to file1 and file2, class C logs only to file 3
> Example 4: How to log to syslog or to the event log (on windouz) - same
> thing

I will write about this - but basically examples 2., 3., 4. - you can
implement them in so many ways.
One way is to use formatters and destinations - as defined by my
logging lib.
But in case you find a faster way, you can simply use that (see the
Workflow of processing a message)


> And so on. The bottom line is: if I evaluate your library, I want to see how
> I can use your library to perform simple, concrete tasks that your library
> is supposed to me with. I want to see the 5000ft view of your library -
> which is what I can and can't do with it, then I want to "sample" it with
> simple examples that try to solve some sketchy real world requirements.
>

You're right. As said, there's more docs to be added - what you want
is definitely in my TODO list.

> May I make the suggestion that it would probably be better to have the
> examples as full compilable applications that can be downloaded.

There are fully compilable examples - see the 'tests' directory.

> I know you all have time constraints - it is free software in the end - but
> if you spend more time to present it in a friendlier way to your users (that
> in the best scenario otherwise changes in the library might be required), I
> think more and more people would feel compelled to use the boost logging
> library.

Again, I'll do that - thanks for the feedback

Best,
John


--
http://John.Torjo.com -- C++ expert
.... call me only if you want things done right


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