Saving in binary files

Question

I've been working on a project for the past few days that involves three linked lists.

Here is an example of the header with the nodes and the lists themselves:

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

Answer 1

This won't help you with your concrete problem at hand but I think you should use standard containers like std::vector<>. Implementing your own linked list is a nice finger exercise but seldom really necessary. That said, you should use std::vector<no_produto> instead of lista_produto:

#include <vector>

std::vector<no_produto> my_lista_produto;

// fill the vector:
my_lista_produto.push_back(my_no_produto_1);
my_lista_produto.push_back(my_no_produto_2);
// ...

// retrieve one item:
const no_produto &p = my_lista_produto[1];

// clear all items:
my_lista_produto.clear();

A complete list of all available methods can be found here.

Concerning your question: The question title mentions inheritance but there isn't any inheritance used in your example. In order to derive class B from class A you have to write

class A {
public:
    void func();
};

class B : public A {
public:
    void gunc();
};

This means essentially, B can be treated as an A. B contains the content of A and exposes the public interface of A by itself. Thus we can write:

void B::gunc() {
    func();
}

even though B never defines the method func(), it inherited the method from A. I suspect, that you didn't inherit your classes properly from each other.

In addition to my initial thoughts about writing you own linked lists, please consider also composition instead of inheritance. You can find more information about the topic at Wikipedia or on Stack Overflow.

Answer 2

So lista_vendas::novaVenda needs to call lista_produto::escolheProduto.

To call lista_produto::escolheProduto you need a lista_produto object. Where are you going to get that lista_produto object from?

There's really only three ways this can be done. I don't know which way is the correct way for you, but I'll list them and you can decide.

1) Have a lista_produto global variable, a global list of products. Then lista_vendas::novaVenda can use the global lista_produto to call lista_produto::escolheProduto. This is the simple solution, but global variables are rightly considered bad style. It also means that you program can only have one list of products, is that a problem? Think carefully before trying this solution.

2) Have a lista_produto as a member variable of lista_vendas or no_vendas. I guessing here but perhaps something like this

class no_vendas
{
public:
    unsigned int codigoVenda, dia, mes, ano, numeroItens;
    double precoTotal;
    lista_produto productList; // list of products
    no_vendas* proxi; //referencia para o proximo no
};

Now each vendor has a list of products, which makes sense. So lista_vendas::novaVenda now has access to a lista_produto in each no_vendas and it can use that to call lista_produto::escolheProduto. If this makes sense then this is problably the best solution.

3) Pass a lista_produto as a parameter to lista_vendas::novaVenda. Like this

void novaVenda(unsigned int codigoVenda, lista_produto* productList);

So whatever code calls lista_vendas::novaVenda must also supply the lista_produto that it needs.

As I said I don't know which of these possibilities is correct, because I don't know what you are trying to do (and I don't speak Spanish). But this is a problem in the relationships between your different objects. It's up to you to design your classes so that they can access the different objects that they need to work.

You mentioned inheritance in your title, but this doesn't feel like the right thing to do in this case.