I have adapted a program that implements a register of players and stores the players in a struct, with BIN file handling. Now it's not possible to use the records after they have been loaded from the BIN file. The compile is ok and both functions below are excuted without crash but when one of the struct variables are read after the BIN file has been input, then the program will crash (segmentation fault).

I'm not sure any more that this will be possible to implement file handling like this with an array of struct due to that each record will have a variable size (variable size of the strings). The examples I have seen and tested works when each player is defined like this:

Player player1;
Player player2;

This is the code that does not work.:

const int SIZE = 200;
struct Player
   {
      string name;
      int age;
      int goals;
      string team;
   };
Player player[SIZE];

int main()
{

/* input of players in main both at start of the program from file and with cin
   number of players are stored in numberOfplayers
  the function output to file is called from here when the program is terminated
*/
}
int WriteToFile(string FILENAME, const Player player[], int numberOfPlayers)
   { 
      ofstream ofile;
      ofile.open(FILENAME.c_str(), ios::out | ios::binary);
      if(!ofile)
         {  
            cout << "Not possible to open the file" << endl; 
            return 1;
         }   
      ofile.seekp(0); 
      for (int i =0; i < numberOfPlayers; i++)   
         {
            ofile.write((char *)&player[i], sizeof(Player) );      
         }   
      ofile.close();
   }
int ReadFromFile(string FILENAME, Player player[])
   { 
      ifstream ifile; 
      long numrecs;
      ifile.open(FILENAME.c_str(), ios::in | ios::binary);
   
      if (!ifile) 
         {
            cout << "Not possible to open the file" << endl;
            return 0;
         }

      ifile.seekg(0L, ios::end);             // go to end of file
      numrecs = ifile.tellg() / sizeof(Player);
      ifile.seekg(0L, ios::beg);            // go to start of file

     for (int i = 0; i < numrecs; i++)
         {         
            ifile.read((char *)&player[i], sizeof(Player) );
         }
      ifile.close();
      return numrecs;
   }

Thanks, I have to find another way of storing the array.

I'm not sure anymore why this code doesn't work when it's possible to output an single instance of the same struct to a binary file. I.e This case work's:
Player player1;
This case does not work
Player player;
The same strings are define in both case's.

Dunno, I can't see your code from here.
It would work if you did everything right, but since it doesn't, I'm guessing you need to fix something.

Thanks Salem, you are right, I have to fix something namely the struct declaration. I have copied some existing code and am adapting it to binary file output. (Type of homework in a the C++ course) I didn't notice until now when I was going to post more of the existing code that the struct declaration differs between the case that works and the case the gives segmentation fault.
The struct declaration that does not work contains C++ strings:

struct Player
   {
      string name;
      int age;
      int goals;
      string team;
   };

And the struct declaration that works contains C strings like this:

struct Player
   {
      char name[30];
      int age;
      int goals;
      char team[30];
   };

The later declaration gives a fix size for each record. It has nothing to do with how the instances are created. Thanks again.

Edited 3 Years Ago by mike_2000_17: Fixed formatting

One more question if you don't mind. Why can't the compiler give a hint about the error? ( or at least a warning). Now it is not noticed until the program crash.
I have compiled with g++.

Languages like C and C++ are far too flexible to diagnose ALL possible run-time faults at compile time.

If you post an exact run-time error message, we might be able to tell you where to start looking.

I don't need to dig deeper into this, I know the reason now why it crashes and can also modify the code. If I hadn't made this post yesterday and received your help then I probaly still would be tracing the bug. Thanks again.

This question has already been answered. Start a new discussion instead.