First of all, sorry for the late reply - I really missed this message.
Need to buy that pair of glasses
I think I probably explained my one point too much in my previous
message
The whole point of my message really was simply to ask for
any boost::logger to provide a feature that allows me to pass in any
logger type to a library at runtime, without that library knowing the -
exact templatized type- of the logger when it was compiled.
Just about everything in my message other than this feature request
was simply my description of what I think are natural consequences of
providing this feature. If you can get around them somehow, that's
great. But I think that in order to provide this feature you must
provide a basic interface that will never change. That's not to say
that it can't be customized for the applications direct use, but there
must be a basic interface there somewhere.
I don't agree with forcing this here. Note: I do provide all the
needed things for *you* to do this, if you truly want.
I haven't completed the docs, but you can check out the code
(it's the logger<gather_msg,default_> class). Also, if you want to try
this, please take the latest code from SVN.
On another note, you can give me a clear scenario, and I'll include it
in the docs - with an example as well
We can continue this talk off
list - you can find my email address on my site.
It's not the compilation time that matters, it's the fact that I as a
library writer may not have given you the source code to recompile at
all. And yet it would still be useful for me to provide an interface
that will accept some boost::logger for me to log to it.
Again, my lib allows for that. If you - as a *client* of my lib, want
to provide for this, you can certainly do it - no problem.
Again I think this is a natural consequence of being able to pass -
some logger- into a library. You don't require that the application
pay attention to these levels, or even that the levels are mandatory
for logging a message in the basic interface, simply that they exist
for the library to use should they choose. There is a fundamental
disconnect between the application and the library, there is simply no
way to at application compile time tell the library the details about
the logger type, some minimal details need to be known ahead of time.
I would assume that the fact that you use levels or not has a big
impact on your application/and how you present this to your clients.
In the toast::logger, I provide two functions, message and
forced_message. message is safe and does the check on your behalf,
forced_message logs regardless leaving you responsible for doing the
check. I think that efficient logging is very important, it's one of
the primary motivations for my having written the toast::logger, but
it's only important sometimes. The most convenient interface possible
is the most important the rest of the time.
Fine by me
If you want to force logging, just use the logger object
directly (instead of a macro).
However, I don't really think it should be the programmer's choice to
force logging a message.
This choice should be somehow centralized, and eventually changing
this should be able at runtime. And again, if you really want to force
logging a message - not a problem, just ignore the filter
The point I was trying to make is that there can be no convenient
standard macros, every client of your library uses their own hand
crafted macro, so there is no consistency.
Again, this was asked by others
You can't satisfy everyone.
And I don't see a problem with this - usually you'll use "<<" to do
logging.
Most of the people will probably use this, but there will be a few
which need a different interface - they will have their reason. I'm
gonna let them
From my previous lib I did learn something : everyone has their own
idea of how a logging lib should look like. It's really hard to
satisfy a majority
why make me use macros to have a convenient syntax?? Why not:
log << INFO << "this is a " << "convenient syntax";
This can be made reasonably efficient, although it does increase the
checks from one to one for every <<.
This is a really no no - because you don't want to pay for calling
time-consuming function(s) if the message will not be logged:
LDBG_ << "some msg " << some_time_consuming_func();
Also, defining you macros is rather easy, and the only difference from
what you've shown, is that you'll have some macro as the first word:
// or something similar
LINFO_ << "this is a " << "convenient syntax";
Please check out the scenarios and their code, to see how simple it is
to create your own macros:
http://torjo.com/log2/doc/html/common_scenarios.html
If the convenient syntax I mentioned just above is in your critical
path (i.e. your profiler tells you logging is slowing you down), then
I can surround it with an if:
if(log.check(INFO)) // confirm that info messages will be logged:
log << INFO << "good old " << "convenient syntax";
I would only do this if necessary for performance. And if it was
necessary a LOT, then I might consider writing a macro. I think that
recommending macros from the start though is not a great idea, and I
think that you should provide the convenient interface without the
macros.
I'm not a big fan of this. Here's why: if people will know that
logging will happen no matter what, most C++ programmers will think
twice before logging something - you'll end up with just too little
logged info. Knowing that logging can be turned off is a big relief
However, it's not that hard to allow users to do logging without
macros.
implicit conversion to bool can cause all sorts of unexpected
conversions. Better to use an 'unspecified-bool-type' like a pointer
to member function.
That's doable
However, I have completely separated logger from
filter concepts. So there's no operator bool() anymore
Best,
John
