Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

C++ Programming

Open File


Hi
I am a student doing a project using C++ builder. I hava a problem in
opening  a number of files more than 47, when run it only it create 46
file, Please help me to be able to create any number of files. Thanks
to your efforts.
Mohd Klaib
Example :

 FILE *out[100];
 char filename[100];
 int noFiles=78;

   for (int i=0 ; i<noFiles ; i++)
                {
                sprintf (filename,"c:/test/TestSuite%d",i);
                out[i]= fopen(filename, "wt");
                 }

This looks more like a C problem.

There isn't a lot you can do if you have hit the number of open files
limit for your system.  You would be better off asking on a platform
specific group.

--
Ian Collins.

Do you really have to have 78 files open *simultaneously*? That's hard
to believe. I suggest you operate on the files one at a time, and close
them when you are finished. Reorganise your code to do this.

john

On May 28, 9:00 am, John Harrison <john_androni@hotmail.com> wrote:

For a student project, maybe, but there's nothing particularly
extraordinary for a server to have several hundred files open
simultaneously.

> I suggest you operate on the files one at a time, and close
> them when you are finished.

That would mean opening the files for each request, and closing
it at the end of the request.  Which would slow things down
considerably, and wouldn't necessarily help, since different
threads (different client connections) will still access
different files.

--
James Kanze (GABI Software)             email:james.ka@gmail.com
Conseils en informatique oriente objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Smard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34

On 5 28 , 2 07 , mom.kl@gmail.com wrote:

Maybe you can use Windows API e.g. OpenFile(...). But I don't know how
much files can be opened simultaneously by this API.
On 5 28 , 8 01 , kingfox <foxap@gmail.com> wrote:

I just wrote a program to test how many files can be opened by Windows
API - OpenFile. This program open more than 5000 files simultaneously.
So I think OpenFile can fit your request. The program as below:

//------------------------------------------------------------------------- -------------------------
#include <iostream>
#include <vector>
#include <sstream>
using namespace std;
#include <windows.h>

void closeFilesByAPI(HANDLE fileHandle)
{
   CloseHandle(fileHandle);

}

void howManyFilesCanBeOpenedByAPI()
{
   vector<HANDLE> handleVector;
   HANDLE fileHandle;
   int count = 0;
   DWORD writtenBytes;
   do {
      stringstream fileName;
      fileName.clear();
      fileName << "file" << count;
      fileHandle = CreateFile(fileName.str().c_str(), GENERIC_WRITE,
FILE_SHARE_WRITE, NULL, CREATE_NEW, FILE_ATTRIBUTE_NORMAL
+FILE_FLAG_RANDOM_ACCESS, NULL);
      if (fileHandle == INVALID_HANDLE_VALUE)
         break;
      handleVector.push_back(fileHandle);
      WriteFile(fileHandle, fileName.str().c_str(),
fileName.str().size(), &writtenBytes, NULL);
      cout << fileName.str() << '\r';
      count ++;
   }while(fileHandle != INVALID_HANDLE_VALUE);
   cout << "Total number of files opened by ofstream is: " << count <<
endl;
   for_each(handleVector.begin(), handleVector.end(),
closeFilesByAPI);
}

//------------------------------------------------------------------------- -------------------------
mom.kl@gmail.com a crit :

> Hi
> I am a student doing a project using C++ builder. I hava a problem in
> opening  a number of files more than 47, when run it only it create 46
> file, Please help me to be able to create any number of files. Thanks
> to your efforts.

You can have a look at the _NFILE defines in stdio.
It should give you the maximum number of file you can open with fopen.

Try to display errno and associated error with perror upon open failure.
It can help you identify the problem.

In your program:

sprintf (filename,"c:/test/TestSuite%d",i);
out[i]= fopen(filename, "wt");
if(out[i]<=0)
{//error
perror(filename);

}

Michael
In article <R5v6i.7694$zL6.7@newsfe7-gui.ntli.net>,
john_androni@hotmail.com says...

[ ... ]

> Do you really have to have 78 files open *simultaneously*? That's hard
> to believe. I suggest you operate on the files one at a time, and close
> them when you are finished. Reorganise your code to do this.

On many systems, opening or closing a file is a fairly expensive
operation, so this is likely to have a significant performance penalty.

It's technically off-topic, but most standard libraries I've looked at
had this limit set in a fairly easy-to-find definition. Adjust the
definition, re-compile the library, and you're off and running.

As long as we're off-topic: elsethread OpenFile was mentioned. MS
considers this obsolete, and new code is encouraged to use CreateFile
instead (though OpenFile probably isn't any more likely to disappear any
time soon than parts of C++ that have been deprecated...)

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

On Mon, 28 May 2007 18:24:47 +1200, Ian Collins <ian-n@hotmail.com>
wrote in comp.lang.c++:

Looks like an obstructionist problem.

Wait, let me double check...

Yes, both sprintf() and fopen() are defined in the latest version of
the C++ standard.

In fact with addition of:

   #include <cstdio>
   #include <cstring>
   using namespace std;

...and placement inside a suitable function, the user's snippet is
100% perfectly conforming standard C++ code.

Even with the addition of:

   #include <stdio.h>
   #include <string.h>

...the code is conforming, although deprecated.

> There isn't a lot you can do if you have hit the number of open files
> limit for your system.  You would be better off asking on a platform
> specific group.

Your advice is quite correct, but your comment is completely
incorrect.  If you don't like using standard C++ library functions
that happen to be inherited from C, that's fine and dandy.

But no use of a function defined by the C++ standard is a "C problem".

Believe it or not, the C standard says absolutely nothing at all about
the behavior of fopen() or sprintf() in a C++ program.  Anything and
everything in a C++ program is off-topic in C language groups.

The fact that C++ defines some functions with the same names as those
in the C library, and defines them to accept similar parameters and
return similar values, does not make them C functions when used in a
C++ program.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

On Mon, 28 May 2007 18:56:38 -0500, Jack Klein wrote:
> Even with the addition of:

>    #include <stdio.h>
>    #include <string.h>

> ...the code is conforming, although deprecated.

Why should this be conforming? These are implementation specific header
files that need not work with anything but the specific C compiler they
are part of.

Of course in practice many vendors offer C and C++ compilers and design
there C system header files in such a way that they are compatible with
their C++ compiler but that is certainly not a requirement of either the
C or C++ standard.

--
Markus Schoder

On May 29, 10:02 am, Markus Schoder <a3vr6dsg-use@yahoo.de> wrote:

Thank you for your advises and help.
klaib

Jack Klein wrote:
> On Mon, 28 May 2007 18:24:47 +1200, Ian Collins <ian-n@hotmail.com>
> wrote in comp.lang.c++:

    [...]

> Your advice is quite correct, but your comment is completely
> incorrect.  If you don't like using standard C++ library functions
> that happen to be inherited from C, that's fine and dandy.

The original code was bad C++, even if it is legal.  (Goto is
legal C++.  Even gets() is legal C++.  That doesn't mean that
they are good.)

> But no use of a function defined by the C++ standard is a "C problem".
> Believe it or not, the C standard says absolutely nothing at all about
> the behavior of fopen() or sprintf() in a C++ program.

It most certainly does.  The definition of these functions in
the C++ standard is: "see ISO 9899".

> Anything and
> everything in a C++ program is off-topic in C language groups.
> The fact that C++ defines some functions with the same names as those
> in the C library, and defines them to accept similar parameters and
> return similar values, does not make them C functions when used in a
> C++ program.

The fact that a C++ compiler can sometimes compiler pure C
doesn't make a program in pure C++ C++.  It's not clear whether
the original poster was trying to write C or C++.  If he's
trying to write C++, he's going about it wrong, as there are far
better solutions in C++.

--
James Kanze (GABI Software)             email:james.ka@gmail.com
Conseils en informatique oriente objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Smard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34

On May 29, 4:02 am, Markus Schoder <a3vr6dsg-use@yahoo.de> wrote:

> On Mon, 28 May 2007 18:56:38 -0500, Jack Klein wrote:
> > Even with the addition of:
> >    #include <stdio.h>
> >    #include <string.h>
> > ...the code is conforming, although deprecated.
> Why should this be conforming?

Because the C++ standard requires it.  The C++ standard also
requires support for "C" language linkage, which more or less
supposes that the C++ compiler "knows" about at least one C
compiler on the target platform.  (The C++ standard doesn't say
how an implementation is supposed to treat this if there is no C
compiler for the target platform.  To my knowledge, however,
this problem has yet to occur.)

> These are implementation specific header files that need not
> work with anything but the specific C compiler they are part
> of.
> Of course in practice many vendors offer C and C++ compilers and design
> there C system header files in such a way that they are compatible with
> their C++ compiler but that is certainly not a requirement of either the
> C or C++ standard.

There is a a requirement in the C++ standard that the headers
stdio.h and string.h exist in the C++ implementation, and that
they have very specific semantics, which are subtly different
than those of C.  In practice, most implementations do use the
same headers (with a few #ifdef's) in both C and C++, although
this normally results in the headers not being fully conform to
the C++ standard.

--
James Kanze (GABI Software)             email:james.ka@gmail.com
Conseils en informatique oriente objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Smard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34

<rant snipped>

Was all that nonsense really worth the effort expended typing it?

--
Ian Collins.

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc