RE: [boost] Proposal: Logging library

From: Otto Hirr (otto.hirr_at_[hidden])
Date: 2002-04-10 09:23:49

I very much agree with the need for a logging mechanism.
I personally use a hack originally developed from free
sw by Fred Fish back in the '80s.  I've adapted it from
the c to c++, vb, and perl. (But it is not thread safe.)

I'm new to the group, so I'm not sure what you consider
or not, however the is a logging service specification
standard within the OMG.  It is under the Telecom area.
see http://www.omg.org/technology/documents/formal/telecom_log_service.htm
I think that ACE/TAO has an (extensive?) log mechanism.

Instead of reinventing, it may be good to scan what is
out there already either in implementation or in what
people are perceiving as needs.  Not that they all
should be met with a bloated overweight implementation,
but something that could be extensible.  I also know
that some of the open sw projects have their own logging
mechanisms, which would be good to scan for their use
patterns.

Best regards,

.. Otto

Otto Hirr
OLAB Inc
503.617.6595
otto.hirr_at_[hidden]

> -----Original Message-----
> From: boost-admin_at_[hidden]
> [mailto:boost-admin_at_[hidden]]On
> Behalf Of Hoeffner, Detlef
> Sent: Wednesday, April 10, 2002 1:46 AM
> To: 'boost_at_[hidden]'
> Subject: [boost] Proposal: Logging library
>
>
>
> A logging library is definitely something that is missing in boost.
>
> Having partially implemented and heavily used such a library in a
> productive multithreaded C++-server application I will list some
> requirements our implementation (which is running under
> Windows and Solaris)
> fulfilled and which I believe a standard logging library
> should fulfill.
>
> 1) std::ostream interface for writing messages
> 2) Support for several categories which can be enabled or
> disabled through
>    configuration
> 3) Configurable output targets for each category
> 4) Configurable general format and standard elements of the output per
> category
>    (and target), e.g.
> "category|timestamp|threadid|namespace::class::method|message".
> 5) Small runtime overhead if looging for a category is disabled during
> runtime
> 6) No runtime overhead if logging for a category is not required for a
> build, e.g.
>    if looging for category trace is not required in a release build
> 7) The logging system shall be usable in the startup phase
> (before main is
> reached)
>    as well as in the shutdown phase (after main).
> 8) The logging library shall be usable in a multithreaded
> application and
> provide atomar
>    output for "one" whole message.
> 9) Depending on in which method or function (alternatively in
> which file)
> the logging is done,
>    output might be enabled or disabled through configuration.
>
> Providing a complete general logging library is difficult because some
> features
> might only be provided in a platform dependent manner. In
> particular this is
> true for nice
> features like retrieving the qualified name of the calling
> method. In my
> opinion this
> feature is very helpful and a general logging library should
> provide support
> for that
> on platforms where this can be supported even if it can't be
> provided on all
> platforms.
> Otherwise users might decide not to use the library in favor
> of another
> library that
> supports this feature.
>
>
> Regards
>
> Detlef
>
> --------------------------------------------------------------
> Dipl. Wirtsch.-Ing. Detlef Höffner
> c/o Commerzbank AG
> Tel. [phone]
> e-mail: Detlef.Hoeffner_at_[hidden]
>
> Tel. [phone]
> e-mail: Detlef.Hoeffner_at_[hidden]
>
>