🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: borland.public.cppbuilder.oodesign
3 messages
3 total messages Started by Ronald Boucher Fri, 27 Aug 2004 16:55
Function call to pull chip info & save to file. Problem shows after 45 calls.
#92
Author: Ronald Boucher
Date: Fri, 27 Aug 2004 16:55
30 lines
2105 bytes
I have created a function which pull the data info from a chip and save & append to a single file, then returns a int value which indicate success/failure.

When I click the button to call the read/dump function about 45 times, the file somehow cannot be opened.  I checked out the memory address of file object "fp" (from FILE* fp declaration).  After 45 times, the fp address turned out to be null... I wonder if that means the fp address has ran out of place to open an new address?  I had to restart the application to continue with the rest of the chips after 45 calls.  How do I reset the memory address or keep it the same?  The file name is generated, depending on validity of the chip, line number, date, and the program name.  Anyone help? 

Sample Code: 
(note: output variable is char[] array for chip info.)


#include <fstream.h>

int Dump::DumpCRUM(char mode) 
// mode variable is used for either 'f'ilter or 'm'ain modules
{
  // FileName string is generated
  
  ofstream dumpfile(FileName.c_str(), ios::app);
  if (!dumpfile)
    {
      return -1;
    }
  else
    {
      dumpfile << output;
      dumpfile.close();
    }
  return 1;
}

I haven't created a constructor & destructor in this Dump class.  Perhaps this will help?
Re: Function call to pull chip info & save to file. Problem shows after 45 calls.
#93
Author: Jurko Gospodneti�
Date: Fri, 27 Aug 2004 17:43
14 lines
1367 bytes
  Hi Ronald.

  My guess is that you are running out of OS file handles but
I could not see anything wrong with the code snippet you
posted.

  Did you just try to call this function in a loop without
actually reading external data but writing some dummy
hardcoded string instead. If that works then my prime
suspect would be some kind of a leak in your some other
part of your program.

  Regards,
    Jurko
Re: Function call to pull chip info & save to file. Problem shows after 45 calls. (PROBLEM SOLVED!!!!)
#94
Author: Ronald Boucher
Date: Mon, 30 Aug 2004 13:29
36 lines
2652 bytes
"Ronald Boucher" <ron.boucher@xerox.com> wrote:
>
>I have created a function which pull the data info from a chip and save & append to a single file, then returns a int value which indicate success/failure.
>
>When I click the button to call the read/dump function about 45 times, the file somehow cannot be opened.  I checked out the memory address of file object "fp" (from FILE* fp declaration).  After 45 times, the fp address turned out to be null... I wonder if that means the fp address has ran out of place to open an new address?  I had to restart the application to continue with the rest of the chips after 45 calls.  How do I reset the memory address or keep it the same?  The file name is generated,
>depending on validity of the chip, line number, date, and the program name.  Anyone help? 
>
>Sample Code: 
>(note: output variable is char[] array for chip info.)
>
>
>#include <fstream.h>
>
>int Dump::DumpCRUM(char mode) 
>// mode variable is used for either 'f'ilter or 'm'ain modules
>{
>  // FileName string is generated
>  
>  ofstream dumpfile(FileName.c_str(), ios::app);
>  if (!dumpfile)
>    {
>      return -1;
>    }
>  else
>    {
>      dumpfile << output;
>      dumpfile.close();
>    }
>  return 1;
>}
>
>I haven't created a constructor & destructor in this Dump class.  Perhaps this will help?
>

This code was written on the dump.cpp file. I have investigated from our original source code and spotted one thing I missed. I realized that when creating the filename string, it caused the stream buffer to overflow. So I had to add one line code (just after "dumpfile.close();") with "FileName = NULL;". This will help to free up the file stream buffer, and to prevent overflow. 
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads