Menu

Program not writing to files.

2007-09-06
2012-09-26
  • Chris Davidson

    Chris Davidson - 2007-09-06

    I have a C++ program that will fail to create files that I am writing to. I am creating a binary file using ofstream. The funny thing is when I am stepping through the code I can get the program to create the files. I think it might have something to do when the program runs and it is going through the code so quickly that it does not have time to write the file. That is the only thing I can think of. I may need something that tells the program to make sure that the data is written to the file. Any suggestions?

     
    • Anonymous

      Anonymous - 2007-09-06

      >> it is going through the code so quickly that it does not have time to write the file.
      It does not work like that, that is not your problem. The writes are buffered, and if the buffer is full, the call will block until it is not. Moreover the operating system provides write caching so that from the point of view of your code a file write is typically as fast as a memory write (because that is what it is!).

      The code you posted in insufficient to diagnose the problem. It is no doubt an error somewhere else and this code is not even executing - perhaps a corrupted dataSize variable is zero or negative. The code may run under the debugger merely because in the different execution environment the memory organisation is such that what gets corrupted, or what it is corrupted with, changes and appears to work. You should check the value in dataSize. Also you may find that if you run the code in the debugger, but let it free-run rather than step, it works - which would exclude your "too fast" theory - the difference then is merely the run-time environment.

      Since you did post some code, I can't think why you would use that loop instead of just:

      bin_out.write( reinterpret_cast<char *>(dataArray), dataSize * sizeof(int) );

      but this is not your problem.

      Also there is no need to do all that flushing. By doing that you are forcing the code to wait until buffered data is written to the file system which may severely affect performance (caching aside). Sometimes but seldom you need to explicitly flush - you almost certainly need not flush in the loop (if you still have one). All buffers are flushed when the file is closed in any case.

      Clifford

       
    • Wayne Keen

      Wayne Keen - 2007-09-06

      Basic 3? Otherwise we are trying to solve your problem with a very vague description of your program...

      Wayne

       
    • Chris Davidson

      Chris Davidson - 2007-09-06

      Here is a bit of my code:

      ofstream bin_out("testfile",ios::out|ios::binary);
      for (int j = 0; j< dataSize;j++)
      {
      bin_out.write(reinterpret_cast<char *>(&dataArray[j]),sizeof(int));
      bin_out.flush();
      }

            bin_out.close();
      

      When I step though the code and stop at the ofstrem line it produces the file. When I compile and run the program it fails to produce the file. It is going through an array and writing out the elements of that array (dataArray). Should be stright forward but I can not see why it would fail to create a file when running the program but passes whe stepping through the program

      Basic3??? Not sure what that means.

      Thanks for any help that can be provided.

       
    • Wayne Keen

      Wayne Keen - 2007-09-06

      "Basic3??? Not sure what that means."

      I guess you didn't bother to read the thread titled, in all capital letters

      "PLEASE READ BEFORE POSTING A QUESTION"

      Please take a moment to actually LOOK at a forum before posting your question.

      Wayne

      p.s. posting a code fragment is almost never a useful thing to do. Providing
      a simple as possible test case that people can run and compile - to see what
      you are seeing is what you need to think about.

       
      • Wayne Keen

        Wayne Keen - 2007-09-06

        An example of where a stand-alone test case can help is that we can tell, for example, if there is
        an issue with variable scope - that has bitten quite a few here - and running things in the debugger
        can effect scope issues, and even behaviour of array indices problems.

        Also, the compile log tells us whether there might be some issues with compile options. Some
        folks think - there is not an error, its a run-time issue - I don't have to post my log.

        Wayne

         

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.