Re: Passing information to printf like functions
On Nov 13, 12:08 pm, Gianni Mariani <gi4nos...@mariani.ws> wrote:
h...@x-formation.com wrote:
...
However I couldn't see if there is a function which allows me to take
the existing arglist and combine it with my own strings.
There is a vsnprintf method.
The problems you cite are one reason why the C++ stream
methods are what they are. The logging interfaces that I have
used more recently have moved totally away from the printf.
Drop the recently, and that corresponds to my experience as
well. The rare cases which did try to use a printf like log
always ended up in trouble. The iostream idiom, on the other
hand, while sometimes a little awkward for some types of
formatting (e.g. tables), is perfect for logs.
A little off topic is another chunk of advice. I have found
that the format of the log information should not be embedded
throughout the application code - it makes it much harder to
implement automated log management tools.
By this, I presume you mean that if it is embedded through the
application code, the format won't be identical everywhere, so
automated tools won't be able to handle it.
In my own work (using the ostream model, of course), the actual
formatting is usually handled by a filtering streambuf. Done
correctly, this can allow different formatting for different
destinations (email, syslog, a file, etc.). More importantly,
it allows multiple destinations, and can ensure synchronization.
The Austria C++ logging interface does things
differently. This is what a typical "log" looks like:
AT_STARTLOG( l_lm, l_loglevel, AT_LOGLEVEL_SEVERE,"SomeDescription" )
at_log("Some Variable") << 55 << 123.456;
at_log("Some Other Variable") << "YUP";
AT_ENDLOG
-or-
AT_LOG( l_lm, l_loglevel, AT_LOGLEVEL_SEVERE,"SomeDescription" )
Yes, AT_STARTLOG and AT_ENDLOG are macros, there are reasons
why it makes sense to do that too.
If for no other reason that you want to automatically make
__FILE__ and __LINE__ available to the logger.
I'm not sure I like the block, though. I use something like:
LOG( severity ) << ...
My experience has been that the more the programmer has to write
to log something, the less will be logged, so I try to keep it
as simple as possible.
In a large body of code using the logging interface, you want
to catch problems with mis-use - the macros make it easy to do
that.
OK - notice that the "at_log" object is local to the body of
code between AT_STARTLOG and AT_ENDLOG. This means you can
place any complex information processing inside the log block
and not pay the penalty otherwise.
The AT_STARTLOG macro contains an "if () {"?
I'm generally very opposed to macros modifying syntax, but I
sort of like this idea. I'll have to check if I can configure
my editor to recognize the strings as opening and closing
blocks, however, so that it will indent correctly.
In practice, I've not had any real problems with my idiom,
above. The operator<< are called for each argument, but they
are inline, and don't do anything if logging is not active, so
in practice, all it means is that I get three or four tests of
the variable, rather than only one. (It also means that if the
programmer outputs complicated expressions in the log, then
these are evaluated. It's been my experience that they don't.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34