Overall, the concept of this class is good. However, here are a few observations:
a) You use callback functions instead of providing virtual functions. I would have expected your logger class to be a base class, and the callbacks to be virtual functions that can be overridden by the user as he/she sees fit. The problem that I have with your design right now is that you made your class a "one and all" class, when it should be a base class. I noted that you responded to one message by saying that you can create a CMaleLoggerBin class. If you used the virtual interface, you wouldn't need to do this -- let the user decide by inheritance what they would like. Of course the logger would do the basic stuff, and delegate any user-defined tasks by calling virtual functions.
b) If you are going to use callbacks, it would be easier if you "typedef"-ed the function pointers. For example:
Now all you need to say is HeaderCallbackProc instead of wearing out your keyboard in several places in your code.
c) The class is MFC based. If I'm writing a Win32 API application or DLL and don't want to or can't use MFC, I'm out of luck. I started to write the equivalent calls to the Win32 API and to the STL classes instead of the MFC container classes.
Overall, it is a good class -- it just needs some improvements that I hope you will utilize in your next version.
Which of the comments i added do you find appropriate, and which you think are not suitable on your opinion ? I am interested in improving my log system too, since i am starting a new project which needs even faster logging, and i am open to all suggestions :)
The current implementation of my log traces messages of 10 words approximately 1000000 times/sec, but i think i can take it up 200%-500% from there.
I have been working on graphic applications before DirectX and OpenGL were publicly available, and that is i so desperately pursue an always faster code ;)
I really like this class, it is very flexible and easy to use.
Unfortunately I think there is a memory leak. If I compile your demo in a debug version and run it, my Developer Studie reports a 112 bytes memory leak on exit? I can't find the problem but I think it has something to do with the way the internal thread is terminated.....
Today evening I reviewed my code and correct some errors.
First, I reject the AfxBeginThread function and start using API CreateThread function instead! This way I solved DLL problem!!!!!
Second, this way I resolved memory leak on application exit!!!!
I'll update my code at this article soon.
Please, wait awhile.
Yes. that's the Microsoft's MFC problem.
... Microsoft tells to export one initialization function within your DLL and then to call it inside your own application right after the AfxLoadLibrary("...") call to create the CMaleLogger's internal thread (by calling StartInternalThread() inside your export function). Maybe this is the solution. I've not tested it yet. If any of you have, please tell me the result.
I'm trying your class in my project but I have some problems when I put it in a dll. In StartInternalThread
function doesn't come back from AfxBeginThread... ProcessThread is valid... The program freezes then...
Can you give any advice?
Today I've tested my CMaleLogger in the strange way. I've tried to direct logging process to the floppy diskette and I've won!!! There is a huge HUGE difference between using a standard method to log and that of mine. It is great when you don't have to care much about the speed of storage media :)
Moreover, I've tested the speed of AddLog function. So... it gives 33455 log messages per second on my computer.
The test has looked like: