Help finding appropriate design pattern for event loggin

[Greg Dharma]

Hello,

I am using C++ for about a year now and am comfortable with the basics
of the language but need some help here with finding a design pattern
for a problem I am trying to solve.

Basically I am trying to log events happening in different classes
(spread across different .cxx files). The events are in most cases
certain checks being done before accessing data from a database. I
need to log which check was done, whether it passed/failed, why it
passed/failed etc.

I am thinking of having a "event collector" class. I will then create
a single object of this class in my program. Then from the various
parts of my code I will call a function like eventCollector-

pushEventInfo(.....)

Now from different parts of the code I would be passing in different
amounts of information (e.g. a couple of strings from one function, a
bunch of int values from another etc). So I would overload the
pushEventInfo function to accept structs of the different types of
info I will be passing to the "event collector" class.

I am wondering if there is any design patten which closely matches
what I am trying to do here. If so, I could read it and clear up any
issues that might occur before I get into implementing my solution to
this problem.

Any other ideas about the general theme of "sending information from
different classes/files to a central location for data collection"
would also be appreciated.

Thanks a lot guys!
Greg.

 

[Maxim Yegorushkin]

I am using C++ for about a year now and am comfortable with the basics
of the language but need some help here with finding a design pattern
for a problem I am trying to solve.

Basically I am trying to log events happening in different classes
(spread across different .cxx files). The events are in most cases
certain checks being done before accessing data from a database. I
need to log which check was done, whether it passed/failed, why it
passed/failed etc.

I am thinking of having a "event collector" class. I will then create
a single object of this class in my program. Then from the various
parts of my code I will call a function like eventCollector-


Now from different parts of the code I would be passing in different
amounts of information (e.g. a couple of strings from one function, a
bunch of int values from another etc). So I would overload the
pushEventInfo function to accept structs of the different types of
info I will be passing to the "event collector" class.

Why can you not use a log file for logging events?

 

[Greg Dharma]

Why can you not use a log file for logging events?

I do not need to log to a file...the utility needs to print out all
information right away to a screen and I do not want many couts/prints
cluttering up the code in various places. I would like to be able to
send event information to a central location and this could then
format the data appropriately and then output it (to the screen for
now) but possibly to a DB or file later (in which case having all data
being collected in a central place would be definitely useful).

Any thoughts/pointers please?

Thanks again!
Greg.

 

[AnonMail2005]

Hello,

I am using C++ for about a year now and am comfortable with the basics
of the language but need some help here with finding a design pattern
for a problem I am trying to solve.

Basically I am trying to log events happening in different classes
(spread across different .cxx files). The events are in most cases
certain checks being done before accessing data from a database. I
need to log which check was done, whether it passed/failed, why it
passed/failed etc.

I am thinking of having a "event collector" class. I will then create
a single object of this class in my program. Then from the various
parts of my code I will call a function like eventCollector-


Now from different parts of the code I would be passing in different
amounts of information (e.g. a couple of strings from one function, a
bunch of int values from another etc). So I would overload the
pushEventInfo function to accept structs of the different types of
info I will be passing to the "event collector" class.

I am wondering if there is any design patten which closely matches
what I am trying to do here. If so, I could read it and clear up any
issues that might occur before I get into implementing my solution to
this problem.

Any other ideas about the general theme of "sending information from
different classes/files to a central location for data collection"
would also be appreciated.

Thanks a lot guys!
Greg.

Take a look at various logging classes (e.g. log4cpp) or write your
own. The logger doesn't have to log to a file, it can output it's
"stuff" to where ever - a file, network, terminal, etc.

The key point is that the outputting is left to that class and the
users of your class do not need to know about those details. Other
key points are the logger is typically a singleton.

Another typical feature is that users of this type of class use
std:stream operators to format their output. This way, your logging
class doesn't need to know about how to output the various things your
client code has to deal with. The logger typically deals with already
formatted output like a std::string.

HTH

 

[Marcel Müller]

Hi,

I do not need to log to a file...the utility needs to print out all
information right away to a screen and I do not want many couts/prints
cluttering up the code in various places. I would like to be able to
send event information to a central location and this could then
format the data appropriately and then output it (to the screen for
now) but possibly to a DB or file later (in which case having all data
being collected in a central place would be definitely useful).

since you have to serialize the information anyway all event classes
should provide a common interface for this job. Furthermore it is
helpful to have some common properties like a severity level. That might
control e.g. coloring in case of screen visualization. And the
collection might calculate some aggregate information like total success
from that. If you want to support filters, more common properties like a
time stamp and context information about the event source, e.g. the
logical component of the application. Individual structures for each
type of event are only useful if there is someone who needs this kind
information in machine readable format. And this is rather unlikely to
happen outside your event classes because it would require RTTI dispatching.

If you do not want to pass a reference to your event collector anywhere
around, you could use thread local storage. For the time of a service
request the TLS could point to your individual request collector. And
once the request is completed the collector is detached from the current
thread. This is an easy and usually high-performance solution.
Unfortunately it requires platform dependencies until C++0x.


Marcel

 

[KjellKod]

I second Marcel's advice.
In addition I would've used some namespace logic &
signals (Qt, Boost, KjellKod signals, sigslot or similar) for making
this loosely coupled
(to avoid having to include or pass around reference to 'event
collector')

Further,. if you are to thread the event collection I strongly
recommend encapsulating it
within an (Asynchronous) Agent,.. communicating with the thread using
a message queue

Kjell

 

[Jorgen Grahn]

I do not need to log to a file...the utility needs to print out all
information right away to a screen

Based on his headers, Maxim seems to be a Unix programmer, so he
probably thinks of a screen (whatever that is) as just another kind of
file.

and I do not want many couts/prints
cluttering up the code in various places.

You mean "the_event_log << stuff << ..." calls I guess -- noone
suggested logging to standard output.

But why would that be more clutter in various places than the event
logging you're already planning? It can be as simple as

mylog << LOGHEAD << result_of_the_foo_check;

(MYLOG being a macro which expands to something which formats file,
line, and/or function name information, if you want those things.)

I would like to be able to
send event information to a central location and this could then
format the data appropriately and then output it (to the screen for
now) but possibly to a DB or file later (in which case having all data
being collected in a central place would be definitely useful).

That still sounds like a std:stream to me.

For one design pattern, have a look at the Unix syslog facility. It's
two or three different functions, you only use the printf-like
function syslog(), and it has been good enough for everybody since at
least the early 1980s. (Except for C++ usage, because it is --
unsurprisingly -- not a std:stream.)

/Jorgen