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

OK, let me explain myself. I do programming in Java part time and I use
log4j to do the logging, and I was looking for a similar library but for
C++. My first choice was log4cpp but then I read your message. I am pretty
sure you did your homework and you took a look at log4j even if it is not a
c++ library - 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
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.
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
}
}

If I want a specialized Logger for my class then I have to map it to a
specialized logger in the configuration file. Log4j will do the rest.
Otherwise Log4j will use a default logger.

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++?

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?!

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.
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
Example 5: How to log in a multithreaded application. Here you just do a
simple application that starts and stops two threads that log messages
Example 6: How to use a configuration file to configure the logging.

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.

After I checked your examples, and having the experience with log4j, I just
can't go any further exploring and testing your libary. It is too
complicated for my taste and I don't want to spend any more time to dig into
it. I would rather build my own Logger class that simply logs to a file.

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

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 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.

B.C.


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

On Mon, 15 Oct 2007 03:24:03 CST, "B.C." <bc@y.com> wrote:
>Using your libraries:
>- Can you change the logging levels at runtime without having to recompile
>the application?

Should be no problem for any logging library.

>- 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++?

Java is a much more dynamic language than C++. Everything (almost) is
an Object and be accessed by reflection. You cannot assume the same
flexibility from C++. But you can at least ask for a library that
shields the configuration options from the user interface.


--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

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

> 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! ]

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! ]

> OK, let me explain myself. I do programming in Java part time and I use
> log4j to do the logging, and I was looking for a similar library but for
> C++. My first choice was log4cpp but then I read your message. I am pretty
> sure you did your homework and you took a look at log4j even if it is not a
> c++ library - 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
> 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.
> You can assign names to loggers, and usually the names are complete class
> names including the package name.

You may want to check out POCO Logging package (part of the Foundation
library)

http://pocoproject.org

Alex


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

> 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 checked the examples in both and I must say my brain went a bit numb.
>
Is this simple enough?
(knowing what it actually does for you)

http://svn.boost.org/svn/boost/sandb...one_logger.cpp

(basically I'm making the lib easier to use - more examples coming
soon )

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! ]

> Is this simple enough?
> (knowing what it actually does for you)
>
> http://svn.boost.org/svn/boost/sandb...ing/samples/sc...
>

I've added a few scenarios here - to show the flexibility of the lib:

- http://torjo.com/log2/doc/html/index.html
- http://torjo.com/log2/doc/html/common_scenarios.html

Feedback is most welcome!

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! ]

>
> 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

As long as you provide reasonable defaults, this really should not be
an issue.
When someone wants to do advanced usage, fine, he'll learn more.
Otherwise, just use something predefined.

I think the best combination is to provide a generic lib, and provide
defaults for different "Usage scenarios" - that's what I've done:
http://torjo.com/log2/doc/html/common_scenarios.html

On a different note, I've made the lib much easier to use. So, to
define a logger using formatters/destinations, you can be happy with
the defaults:

typedef logger< use_format_write<formatter_base,destination_base> >
log_type;

The class use_format_write hides away most of the complexity behind
choosing policies. For instance:
http://torjo.com/log2/doc/html/commo...on_scenarios_3

> 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

Just as a side-note - I don't see this as a disadvantage


--
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! ]