Hello and thanks for reading!

I'm having a bit of a problem with writing to a file in a C++ program.

Program structure:
My "main()" function calls a "Process" function which calls another function "PowerLimit". PowerLimit has 5 member variables and I would like the values of these member variables to be logged to a file each time PowerLimit is called.

Outside "main", I declared the following:


My question is where do I assign pOutputFilePointer to an actual location?
i.e. where does the line

go?

Should I put that in "main", "Process" or "PowerLimit"?

Also, will the following syntax work for the actual writing to file?


( I know that the elipsis will not work )

I want the values of the parameters to be appended to the file.

Thanks for your help!

I also have a related question:

The above program is part of DSP code that runs on an Analog Devices DSP. The "Process" function (which calls the "PowerLimit" function) operates on individual input samples.

The start/stop of the application are determined by when I press Run/Halt in the IDE.

Do I need to close the file after every write operation? Is there anyway that I can close the file when I halt the processor?

In standard C, all open files are closed automatically when the program returns from main() (although "good programming practice" is to fclose() all files that your program fopen()ed). If the program terminates abnormally, data that are in the output buffer of any open files may not be written to the disk by the operating system. If the "halt" from the IDE is a breakpoint rather than a program exit, the IDE may or may not make sure that buffers are flushed each time (I have seen some that do, and I have seen some that do not --- which is a real pain).

I don't ever recommend use of global variables unless absolutely necessary (occasionally, but not often, in my experience). If you want to open the file in one function (main(), for example) and write to it in another function, I would recommend that you pass the FILE pointer as a parameter.

In your case, if you only write to the file in one function, you could open the file each time, append the data, and close the file again, all within that function. If the file name is not known until run time (from a command line argument or from user input, for example), you could pass the file name as a parameter to the function that is opening and writing to the file.

Regards,

Dave

Thanks, Dave!

I have been experiencing a similar problem when a function is called many times where each time it (the function) is called, a file is fopen()ed, something gets appended to the file, and it is fclose()d. My problem is that when a file is called so many times, an error "Too many open files" will raise even if the file is opened and closed every time the function is called.
I get away with it by defining a FILE* member in the constructor to which the function belongs, and close the file when a destructor is called. I am still not sure though as why it alerted "Too many open files".

Below is the original post about the above mentioned problem. Hope to see more discussions from you.
http://

David

When I tried your link, I got an "Invalid URL" message, so I didn't see the previous discussion.

Here's the way I approach a puzzle like the one you described:

Make a very simple program that does nothing but minimal operations: open for appending, write a line, close.

Make a loop that repeats this 100 times, 1000, times, 10000 times, etc. If it works in the simple program but not in a more complicated program: look, look, look for differences between what works and what doesn't work. I have found one case where, with global variables, some other function was occasionally accessing the file and not cleaning up after itself (that's why I generally avoid global variables --- they make debugging other people's rude programs much more difficult).

So, you could try something like this for test purposes.

You could also comment out the fclose() statement to see how many times it gets through the loop before it chokes. When I didn't close the file, I got the following results on my Windows XP box:

After compiling with Borland bcc32 it, quit with i = 47.
After compiling with Microsoft Visual C++ it, quit with i = 509.
After compiling with GNU gcc, it quit with i = 3097.


I actually ran each with a loop of 1,000,000 times with no problems (took a couple of minutes).

You, of course, must run your own tests.

Good Luck!

Regards,

Dave

Since you talk of constructors, I see that you are using C++. In that case, I strongly suggest that you use <fstream> member functions and not cstdio functions. Now, good old fopen(), fclose(), etc are OK to use in C++ as well as C (that is a requirement of the C++ standard), but why not do things the C++ way? (There are certain advantages, that I don't need to go into here, but that's my recommendation.)

As always, these opinions are just that: opinions. If you decide to do things differently: no hard feelings. There are lots of "correct" ways of doing things, just as there are lots of incorrect ways of doing things.

Regards,

Dave

Dear Dave,

Thank you very much for your comprehensive reply. I have tried to comment out fclose() in MS VC .NET, and similar to your results obtained by VC++6.0, fopen() fails after 509.
The bunch of cpp. that I am currently working on (as a reference software) is not very well written, and as you suggested, it indeed has a number of global variables and functions, and I suppose they may well be responsible for the problem that I have stated in previous posts. I have not looked into the details as why the program, or fopen(), had failed after several calls to the function, as I have had to move on with the project and I can get away with constructors and destructors for the time being. But once I had more time, I will have a thorough test of the program to see how all the globals behave, and I am sure that your words would be very helpful in these regards. Thanks again for the reply.
As for fstream, I do agree with you the C++ way, in fact, I am as well biased towords pure C++, just that I am much less experienced.

Best wishes,
David