Saving in binary files

I have a program that contains 3 linked lists ex:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
class nodeA
{
   int data1;
   double data2;


    nodeA* next;

}
class listA
{
    nodeA* headA;
    ...
}
class nodeB
{
   int data3;
   double data4;


    nodeB* nextB;

}
class listB
{
    nodeB* headB;
    ...
}
class nodeC
{
   int data5;
   double data6;


    nodeC* nextC;

}
class listC
{
    nodeC* headC;
    ...
}



What i'd like to know is how can i save the lists that i declare in my main so that if i close the program and then open it again i can recover the lists data
You can't save the lists only the data.
Might be the easiest to store each list in a separate file.

To load them just construct new lists read the numbers and add them to the lists.
Can you elaborate the way to do this?
These classes are identical. Why are there three of them?
1
2
3
4
5
6
7
8
9
class Node {
    int i;
    double d;
};

class List {
    Node *head;
    ...
};



You can save the data to a file and then read it again when you start the program. I suggest you start with read and write methods (or >> and << operators) for class List. Then you can just dump the lists into a file and read them back again.
These classes are just an example
If you can extract the data from the node, and it contains only POD data (https://stackoverflow.com/questions/146452/what-are-pod-types-in-c ), then simple stream .write() and .read() will suffice.

1
2
3
4
5
6
7
8
9
10
11
12
13
struct data {
  // POD only
  int a;
  double d;
};
struct node {
  data data;
  node *next;
};
struct list {
  node *head;
  node *tail;
};


But if your data contains anything that needs constructing (like say a std::vector or std::string), then it gets messy in a hurry.

C++2x may or may not fix this.
Until then, libraries!
https://stackoverflow.com/questions/234724/is-it-possible-to-serialize-and-deserialize-a-class-in-c
Last edited on
the problem is pointers. if you accidentally send a pointer to the binary file, it will save that, and load it back, but the pointer it loads back will not have been set up and the data under it will have been lost.

if you do this:
struct s{int x, double d;}
and save it to a binary file, its fine.
if you do this:
struct s2{int x; string z;}
it will not work. it will write the raw binary of the string object to the file, yes, but it stores the hidden pointer inside string to the file, not the character data that is pointer to.
c-string arrays work:
struct s2{int x; char z[maxsizealllowed]};
the binary file will allocate maxsizeallowed bytes and put the data from z into them. Its wasteful, but see the 'time space tradeoff' concept.

the same is true for linked lists. if you save struct list, all you get are 2 pointers that when loaded back are not valid.

there are 2 ways to deal with the issue.
you can serialize your data for read and write to a file, either up front by making your lowest level object C-style and pointer free, or you can reverse your c++ object down to the byte level.
in the specific case of a linked list, what you *really want* is for your binary file to look like this: data0data1data2data3.... where data is the thing the list stores, and the file position is your clue as to 'next' (you don't need head, next, any of that at all, its implied by the order of the data in the file).
so what you can do with what you have is traverse the list from head to tail and send just the data items into the list in a safe binary format.

lets put that in action for a pretend list of c++ string objects which for our made up scenario will have a max string length of 100 ascii letters including the zero terminal for c-strings.

list * lp = head;
char tmp[100]; 
while(lp) //stops on the ending null entry in the list
{
 strcpy(tmp, lp->data.c_str());
 filevar.write(tmp, 100);
 lp = lp->next;
}



there are ways to avoid the copy to array safely, but for the concept, just let the inefficiency ride while absorbing the idea. Avoiding the copy makes the underlying concept less visible in the code.
Last edited on
Topic archived. No new replies allowed.