Quote:Original post by dawidjoubert rather keep a log of the last 10 important operations that occured, then keep over writing the old one. This can give you some idea of where the crash occured(in a worst case scenario).
What would that solve? You would still need a closing tag on a BSOD if you use a format needing a closing tag.
I uses a RTF text document for my log. Backing up over the ending tag every time isnt that much of an issue. Only thing that is a real issue is remembering to fflush after every write, so unless it dies in your logging code, there is always the last completed log writen to disk.
Quote:Original post by KulSeran Only thing that is a real issue is remembering to fflush after every write
setbuf(fp, NULL);
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
This might be a complex system, but I think it would be robust:
I would write out a starting and closing tag to start with, then scan back to the inside of it. Subsequently, only write start tags if you can follow them with closing tags. I didn't read the gamedev XML article, I'm only familiar with XML.
Another thing to take a look at is std::atexit(). It sets a function to call when a program terminates. I don't know if it would still work on a crash. If it's a soft Windows crash, maybe. Prob not a BSOD.
Anyway, I really like the idea of always writing the closing tag since it is just a single line. Then, when I write the next log entry, I'll just write over the closing tag and write it again after the log entry.
The only question I have left now, is what would be the easiest way to write over the last line in the file. I'm happy to use either a file HANDLE or a std::ofstream for my reading/writing. However I would probably prefer the file HANDLE so I don't have to rely on STL. But if it is easier with STL, then I'll use that.
xml is very good for a logger it lets u prune the data anyways i have the same issue the solution (from memory though i couldnt get it working, its not high on the TODO list ) is to have 2 xml files the logged entrys are contained in one thus it doesnt have <SystemLog></SystemLog> + the other file contains <SystemLog> body = see other file </SystemLog>
Quote:Original post by zedzeek xml is very good for a logger it lets u prune the data
A straw man argument. Pruning the data neither deals with the problem of abrupt termination, nor is it a feature unique to XML.
Although data pruning and sorting isn't unique to XML, there are a lot of existing free tools for working with XML which makes it an excellent choice if you can solve the abrupt termination problem (which can be done by several methods so far pointed out in this thread).
the best way to ensure that you have written to a file, just before a crash, is to flush the cache to the hard disk.
to do this, you open the Log file with fopen(yourfilename,"wc"); , the "c" in the second parameter allows you to call the fflush(yourfilehandle) command, which inmediately sends the cached data to the hard disk.
So, you just call fflush(yourfilehandle) just after every log write.
Notice that fflush will not return until the data has been physically written to the hard disk, this means that the logging process will be extremely slow. Personally, I have two versions of the log, one without the fflush, and another, just for critical operations, with the fflush, placed just before crash prone code.
