«

Hi all,

I have data that has to be written successively, that is, this data is
updated at every step in the loop and I need to print this in a file.
So, I need something like, for every step, 1.dat, 2.dat....and so on.

If there are 100 successive output files, for that, I guess I need 100
file pointers to be initialized.

FILE *fp_1,*fp_2 and so on..
....
....
....
for (i=0;i<100;i++)
{
fp_no = fopen("C:\\loopno.dat","w");
fprintf(fp_no,"%d, %lf", x[i], y[i]);
fclose(fp_no);
}

I was wondering as to how to do the above...I have been looking for
this since sometime. Can anyone suggest me something on this?

Thanks in advance.

Mokkapati

Mokkapati wrote On 05/18/06 17:37,:
> Hi all,
>
> I have data that has to be written successively, that is, this data is
> updated at every step in the loop and I need to print this in a file.
> So, I need something like, for every step, 1.dat, 2.dat....and so on.
>
> If there are 100 successive output files, for that, I guess I need 100
> file pointers to be initialized.
>
> FILE *fp_1,*fp_2 and so on..
> ...
> ...
> ...
> for (i=0;i<100;i++)
> {
> fp_no = fopen("C:\\loopno.dat","w");
> fprintf(fp_no,"%d, %lf", x[i], y[i]);
> fclose(fp_no);
> }
>
> I was wondering as to how to do the above...I have been looking for
> this since sometime. Can anyone suggest me something on this?

for (i = 0; i < 100; i++) {
char filename[sizeof "C:\\xxx.dat"];
FILE *fp;
sprintf (filename, "C:\\%d.dat", i);
fp = fopen(filename, "w");
if (fp == NULL) ... handle error ...
...
if (fclose(fp) != 0) ... handle error ...
}

--

>I have data that has to be written successively, that is, this data is
>updated at every step in the loop and I need to print this in a file.
>So, I need something like, for every step, 1.dat, 2.dat....and so on.

The argument to fopen() need not be a constant. sprintf() is often
useful in constructing a filename in a character array to pass to fopen().
You don't have to use that, though, there are many ways of constructing
strings from pieces.

From the procedure you describe, you do not need more than one of these
files open simultaneously. One FILE * pointer is enough.

>If there are 100 successive output files, for that, I guess I need 100
>file pointers to be initialized.

Or you can use the same file pointer variable repeatedly. fopen(), write
something to the file, fclose(), repeat.

>
>FILE *fp_1,*fp_2 and so on..
>...
>...
>...
>for (i=0;i<100;i++)
>{
> fp_no = fopen("C:\\loopno.dat","w");
> fprintf(fp_no,"%d, %lf", x[i], y[i]);
> fclose(fp_no);
>}

Gordon L. Burditt

Thanks Mr. Sosman for the example and Mr. Burditt for your insights. I
could run a sample code.

Thanks so much.

Mokkapati

Gordon Burditt wrote:
>Mokkapati wrote:
>>I have data that has to be written successively, that is, this data is
>>updated at every step in the loop and I need to print this in a file.
>>So, I need something like, for every step, 1.dat, 2.dat....and so on.
>
>The argument to fopen() need not be a constant. sprintf() is often
>useful in constructing a filename in a character array to pass to fopen().
>You don't have to use that, though, there are many ways of constructing
>strings from pieces.
>
>From the procedure you describe, you do not need more than one of these
>files open simultaneously. One FILE * pointer is enough.
>
>>If there are 100 successive output files, for that, I guess I need 100
>>file pointers to be initialized.
>
>Or you can use the same file pointer variable repeatedly. fopen(), write
>something to the file, fclose(), repeat.

<OT>
Reusing the same FILE pointer leads to a simpler and cleaner design,
but there are other reasons to do this: Every operating system has
some limit on the number of files that can be open simultaneously,
both on a per-process and system-wide basis.
You may not be able to open 100 files in a single program, even if
your code is 100% correct from the coding and logic points of view.
And if you can open 100 files, that means 100 less are available to
the system as a whole, potentially causing other programs to fail.
</OT>

Roberto Waltman <> writes:
[...]
> <OT>
> Reusing the same FILE pointer leads to a simpler and cleaner design,
> but there are other reasons to do this: Every operating system has
> some limit on the number of files that can be open simultaneously,
> both on a per-process and system-wide basis.
> You may not be able to open 100 files in a single program, even if
> your code is 100% correct from the coding and logic points of view.
> And if you can open 100 files, that means 100 less are available to
> the system as a whole, potentially causing other programs to fail.

Does *every* system impose this kind of limit? I know that many do,
but it's easy to imagine a system where the number of simultaneously
open files is limited only by the amount of memory necessary to
describe them. Such a system would have no fixed-size tables of file
descriptors, for example.

> </OT>

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Keith Thompson wrote:
>
> Roberto Waltman <> writes:
> [...]
[...]
> > You may not be able to open 100 files in a single program, even if
> > your code is 100% correct from the coding and logic points of view.
> > And if you can open 100 files, that means 100 less are available to
> > the system as a whole, potentially causing other programs to fail.
>
> Does *every* system impose this kind of limit? I know that many do,
> but it's easy to imagine a system where the number of simultaneously
> open files is limited only by the amount of memory necessary to
> describe them. Such a system would have no fixed-size tables of file
> descriptors, for example.

I've seen a system which dynamically allocated its tables, but it still
"limited" the number of open files for a process to 2000. (Or was it
20,000? It's been quite a few years. In either case, it was much
better than the 20 file limit imposed by the systems I had previously
used.)

The problem with "limited only by the amount of memory" is that a runaway
program could use all of that memory, so arbitrary limits still have their
place in a multitasking environment. Think "file leak" as a situation not
unlike a "memory leak" with malloc().

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <private.php?do=newpm&u=>

Kenneth Brody said:

> Keith Thompson wrote:
>>
>> Does *every* system impose this kind of limit? I know that many do,
>> but it's easy to imagine a system where the number of simultaneously
>> open files is limited only by the amount of memory necessary to
>> describe them. Such a system would have no fixed-size tables of file
>> descriptors, for example.
>
> I've seen a system which dynamically allocated its tables, but it still
> "limited" the number of open files for a process to 2000.

MS-DOS implementations typically imposed a limit of 20 open files - and that
included stdin, stdout, stderr, and the unfortunately named stdprn and
stdaux - so you were really left with 15. Mind you, that was plenty. On the
one occasion that I needed more, I needed *loads* more - so I simply came
up with a way of keeping track of which ten or so files were busiest, and
kept them open, closing and opening others as and when required.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

>Does *every* system impose this kind of limit? I know that many do,
>but it's easy to imagine a system where the number of simultaneously
>open files is limited only by the amount of memory necessary to
>describe them. Such a system would have no fixed-size tables of file
>descriptors, for example.

It is easy to imagine a system like the above where the system *STILL*
refuses to allow any one process from hogging so many resources that
prevent others from running.

Gordon L. Burditt

Keith Thompson wrote:
> Roberto Waltman <> writes:
> [...]
>> <OT>
>> Reusing the same FILE pointer leads to a simpler and cleaner design,
>> but there are other reasons to do this: Every operating system has
>> some limit on the number of files that can be open simultaneously,
>> both on a per-process and system-wide basis.
>> You may not be able to open 100 files in a single program, even if
>> your code is 100% correct from the coding and logic points of view.
>> And if you can open 100 files, that means 100 less are available to
>> the system as a whole, potentially causing other programs to fail.
>
> Does *every* system impose this kind of limit? I know that many do,
> but it's easy to imagine a system where the number of simultaneously
> open files is limited only by the amount of memory necessary to
> describe them. Such a system would have no fixed-size tables of file
> descriptors, for example.
>
On those platforms where nearly everything requires a file of some sort,
and resources to maintain them, it is pretty easy for a large server
application to hit these soft or hard limits.