A Logger Makes Your Life Easier



Click here for a larger image.

Every programmer needs a way to know what is happening with his application. For example: You write some source code, compile it, and than you are very happy because your app is working. But wait... The strange part begins now: You have some errors in the release version. What would you give to know what is wrong? Enough with this annoying situation! USE A LOGGER!

Java inspires me. So, I've created a logger based on some ideas from java.util.logging. This logger is able to log on multiple "media" files, consoles, TCP connections, and table windows. Soon, I will add support for database logging. This is accomplished by "mounting" and/or "unmounting" those types of handlers into the logger.

The logger also supports seven levels of logging: SEVERE, WARNING, INFO, CONFIG, FINE, FINER, and FINEST. These levels are very well explained in the source code (file "logger.h"). Every media handler has a logging level. If a message arrives to a media, it will be saved only if the media logging level<=message logging level. A good use of this is that you can log severe and warning messages into a file, info, and debug levels to a window with a table and the rest of the messages to the console. This logger's settings are very easy to make. After that, by using the macros defined in the logger, you can log anything you want, anyware you want.

Here are the instructions to make a logger work:

  1. Add logger.h and logger.cpp to your project and make sure that logger.h is accesible by adding the right include directory.
  2. Set logger.cpp not to use a precompiled header. BE CAREFUL. Only logger.cpp needs this!
  3. Include logger.h in the most visible header file from your project. For MFC applications, that file is stdafx.h.
  4. Instantiate a CLogger object as global so that it can be visible from all your project. This isn't a "must." You can use several loggers if you want.
  5. CLogger logger("put your logger name here");
  6. Instantiate some handlers with various levels of logging:
  7. CFileLogHandler fileLogHandler(LEVEL_WARNING,
      "c:\\some\\directory\\file_without_extension");
    CFileLogHandler consoleLogHandler(LEVEL_CONFIG, "ignored",
      -1, TRUE);
    CWndLogHandler wndLogHandler(LEVEL_ALL,
      "The title of the logger window");
    
  8. Add the handlers to the logger:
  9. logger.AddHandler(&fileLogHandler);
    logger.AddHandler(&consoleLogHandler);
    logger.AddHandler(&wndLogHandler);
    

    At this point, you are ready to use the logger. Here are some examples:

    [code]
    ...
    SEVERE_LOG(logger, "severe message.");
    ...
    WARNING_LOG(logger, "warning message");
    ...
    INFO_LOG(logger, "info message");
    ...
    CONFIG_LOG(logger, "config message");
    ...
    FINE_LOG(logger, "fine message");
    ...
    FINER_LOG(logger, "finer message");
    ...
    FINEST_LOG(logger, "finest message");
    ...
    

CFileLogHandler Logs Data into a File

The constructor of this handle needs the following items:

  • LEVEL level—this is the handler level of logging
  • CString fileName—the name of the logging file. If the console==TRUE, this parameter is ignored (logging to console)
  • DWORD maxLength—maximum allowable size of the file. If the size of the file is greater than this value, a new file is created and numerated by adding a number to the end of the file name along with the current system date
  • BOOL console—if TRUE, logs to the console; if FALSE, logs to the specified file
Remarks: The file name should not have an extension. The logger adds the current date and a sequence number to the file name, along with the "*.log" extension.

CWndLogHandler Logs Data to a Window with a Table

The constructor of this handle needs the following items:

  • LEVEL level—this is the handler level of logging
  • CString title—the title associated with the window
Remarks: This handler was tested with 65536 records, 4096 bytes/message.

CSocketLogHandler Logs Data to a TCP Connection

The constructor of this handle needs the following items:

  • LEVEL level—this is the handler level of logging
  • CString host—the destination host. Ex: your.domain.com or IP: 123.24.11.23
  • unsigned short port—the destination port
  • BOOL keepAlive—if TRUE, the connection is not closed. If TRUE, the connection is closed after each message and reopened before sending a message

Downloads

Download source - 12 Kb


Comments

  • Way be satisfied with logging to a file?

    Posted by Legacy on 02/18/2004 12:00am

    Originally posted by: Yngve

    Way be satisfied with logging to a file when it is possible to monitor and control your application in real-time from one remote focal point in your network? If you use AppMind that is free tool from Appmind Software you can do all that and a lot more with minimal coding (sorry for that C-hackers but don't despair this gives you the opportunity to work with your business problem instead). You can also use the bundled console to debug, performance tune and manage your application during development (and in production). After you are done with all this you can surprise your IT operations department by telling them that you have developed a manageable application that they can hock in to their existing surveillance framework if there is one. If not they can use the bundled Developers console for simpler tasks.

    Reply
  • Use this auto trace tool, don't program anymore!

    Posted by Legacy on 02/04/2004 12:00am

    Originally posted by: peng

    This logger must programming. There has an-other tool which didn't need program now. try it now.
    
    

    http://liangs99.myetang.com/pengchunhua/en/

    Reply
  • Thanks finally for someone writing a simple C++ logger

    Posted by Legacy on 01/27/2004 12:00am

    Originally posted by: Josh

    Gavriloaie,

    You rock!

    I have been looking for a replacement for my beloved Log4J but in C++, the C++ port is just overwhelming...

    This is even nicer, its chainsaw as well!

    Josh

    Reply
  • To Imran and Andre!

    Posted by Legacy on 12/09/2003 12:00am

    Originally posted by: Sane Voice

    To Imran:
    Not everyone will arrive at using
    correct soln. Unless you invent your own wheel, you
    will hardly ever want to compare it with someone elses.

    Andre's article gives people idea about using a Logger
    in program. While I agree his approach (of adding classes)
    to project is preety naive, but being Version 1, it
    is definitely worth something.

    By posting article, Andre is willing to share best he has
    got, whereas you who knew more sophisticated soln
    spoke later and only to rebuke him?

    Nevertheless, I do have to thank you for providing
    input (atleast as a rebuttal) and guiding to better
    soln for our work.

    To Andre:
    Maybe you should seriously improve your proverbial wheel
    and retrofit your soln into the one already provided by
    Microsoft thus making your app even better.

    Maybe I missed it, but can you set the required logging
    level at any given time (without recompile)?

    All the best and many thanks to both of you. Keep
    up the good work!

    Reply
  • Nice work

    Posted by Legacy on 12/05/2003 12:00am

    Originally posted by: Edwin

    Good job, thanks!

    Some suggestions:
    1. Auto-size the list control of the log window;
    2. Format the text so easy to read log files;

    Reply
  • Reply to all your claims....

    Posted by Legacy on 12/05/2003 12:00am

    Originally posted by: Imran Khan

    May you have invented biggest invention in this century! By creating CLogger class! But remind you every class needed to be instantiated in on system stack and eventually it need a system resources, which apparently come from main system stack, to simply produce user message or developer need to know which statement got executed, correctly or incorrectly. Beside your Clogger does dos not produce a line number for the execution of which statement got executed!
    
    I strongly suggest you should look for the Debug.h in SDK and you will know what is on the offer because this MS Logging facility demonstrated in the Exchange server development, while developing a add-on connectivity for MS Exchange server such as Fax connector, MAPI connector, or any other custom based connector which could be installed as add-on; which either throw logging message (custom) either at output window or any third party program, even including full day-time stamp, function name, current statement execution; that include file name and line number of statement.

    I don't think, need further evidence to justify how great your invention is which require to add two file to the project header and implementation, to get started and still be struggler to simply throw a messages of your own creativity.
    On such brief note, I would say why not use simple TRACE statements!!!! And all will be hunky dory!

    Reply
  • Re-inventing the SAME WHEEL again and over again...

    Posted by Legacy on 12/04/2003 12:00am

    Originally posted by: Imran Khan

    If this author read the Microsoft MSDN doc correctly then I guess, he do not need to re-write the 'Logger' stuff at all. Because in the MS SDK for give fully ready made logging facility with a single header file, which allow user to log ever details of program either under debug version or release version (minimum in release. Please stop wasting network resources and valuable time.

    Reply
  • improvements for the logger

    Posted by Legacy on 12/03/2003 12:00am

    Originally posted by: noam cohen

    Hi
    Nice start.
    From my experience, if you logger is worth using, you will need two things:
    1. log selected modules only (similar to the DbgLog() in DirectShow).

    2. Logging should be done in a seperate (idle priority) thread. If not, you force the developer to think what is the penalty of writing to the log file(s).

    3. Optimize it anyhow. why do you loop 128 times and not until the first non null handler? etc.
    for (int i = 0; i < MAX_LOG_HANDLERS_NUMBER; i++)
    {
    if (m_logHandlers[i] != NULL)
    {
    if (m_logHandlers[i]->Publish(record) != TRUE)
    {
    ASSERT(FALSE);
    }
    }
    }

    ARE there common log file formats? We have used our own log file viewer (with strong sorting and filtering ). It's best if the log file format can be read by someone who already did this viewer.

    cheers
    Noam.

    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • The explosion in mobile devices and applications has generated a great deal of interest in APIs. Today's businesses are under increased pressure to make it easy to build apps, supply tools to help developers work more quickly, and deploy operational analytics so they can track users, developers, application performance, and more. Apigee Edge provides comprehensive API delivery tools and both operational and business-level analytics in an integrated platform. It is available as on-premise software or through …

  • Java developers know that testing code changes can be a huge pain, and waiting for an application to redeploy after a code fix can take an eternity. Wouldn't it be great if you could see your code changes immediately, fine-tune, debug, explore and deploy code without waiting for ages? In this white paper, find out how that's possible with a Java plugin that drastically changes the way you develop, test and run Java applications. Discover the advantages of this plugin, and the changes you can expect to see …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds