Is the trace file created by RapidCodeObject::TraceFileSet() buffered? Suppose I wanted to check the contents of the file without closing it, could I expect it to contain everything up to that point in time, or would I have to close it to ensure that the contents of the trace are actually flushed to the file?
Alternately, is there a way to accomplish tracing without going through a file? In the end, what I want is to get/keep the trace in memory and send it to my own logging mechanism.
If you don’t use a TraceFileSet, it should print to the standard output. You are likely to get spammed unless you limit the Trace mask though. We don’t have a way to access the buffer or file short of Closing the TraceFile and then restarting it. Is that an option for you?
fflush() would probably do it on your end (or std::flush()). Perhaps you’re using someone else’s library and it’s impossible. You’re the best judge.
I can work with whatever you provide. I was curious. I’m going to proceed optimistically as if you were flushing, even if you aren’t, because there’s no other good way for me to do what I want.
stdout is essentially useless in a GUI app because the process is (usually) disconnected from the console.
If it’s possible to flush in some way, that would be cool, but it’s not a big issue for me. I can imagine that some people might prefer buffered output.
We do use fflush in a secondary library we have the sources to.
The RapidCode way would be Trace(false), TraceFileClose(), Access the file until done, and then Trace(true) to collect more data.
I’m attempting to design a multithreaded solution and it’s possible that two different threads would want a trace for overlapping periods of time. If I stop/start to achieve a flush, it complicates things a great deal to get all the trace information (too much is OK, too little is undesirable) to all the consumers. My thought was that if I could read the output without closing the file, there would be no chance of trace messages getting lost in the moment between close and open and it would be a better solution.
In practice, we don’t always get what we want, and this feature is only a troubleshooting tool. I just wanted to design it with sufficient forethought that I don’t kick myself later for having been lazy.
How much time might elapse between adjacent TraceFileClose() and TraceFileSet() calls? Or, how likely am I to miss trace messages (regardless of elapsed time) between those two calls?
If I called TraceFileSet() while there was still an open trace file, what should I expect? Would it immediately close the first file and open the new one without any possibility of losing trace info?
We designed the TraceFile Logging so we could have a customer record information during a problem and review at a later time. We haven’t done any timing evaluations.
Setting a new file should close the previously one and open the new file. I don’t know how long the fclose and fopen processes take. There could be some data loss.
Good enough. I’ll work within the existing limits of functionality. Thanks for the info.