I have 'manually' done something similar to what I suspect you want to do.
For the non-simple type (DataPktType) you might consider the following crude outline (if only to help get you started).
First, I added 2 virtual methods to all classes that needed to participate - in my case, we called them store and restore. These methods dealt only with the data attributes of their own class.
restore() was, in some sense, the inverse of store().
struct SType{
int Num;
char Word[20];
char sugg[20];
virtual void store(ostream& os);
virtual void restore(istream& is);
};
struct DataPktType
{
list<SType> MyList;
char filename[MAX_SIZE];
int numslaves;
virtual void store(ostream& os);
virtual void restore(istream& is);
};
So, where DataPktType.store() might transfer every POD data attribute into the ostream:
DataPktType::store(ostream& os)
{
os << MyList.size(); // gotta know how many to extract later
for (auto it = myList.begin(); myList.end(); it++)
{
it->store(os); // tell the SType to store itself at this point in the stream
}
os << filename;
os << numslaves;
}
Then, the 'inverse' might be something like
DataPktType::restore(istream& is)
{
size_t listSize = 0;
is >> listSize;
// input error checks
for(size_t i=0; i<listSize; ++i)
{
SType listItem;
listItem.restore(is); // assumes the list item contents are 'next' in the file
MyList.push_back(listItem); // I don't use std::list often,
// there seems to be several choices for adding to a list
}
is >> filename;
is >> numslaves;
}
These are the kinds of things I think you need to do.
Notice no pointers go into the streams.
Notice that the symmetry is not perfect, but you will have to figure out how to handle each action.
In my effort, I believe I added some simple checks along the way ...
Also, my team used text for the first implementation. As a human, that will be much easier to debug, and you can use an editor to debug 'symmetry' issues.
Furthermore, you may find that the text i/o performance is adequate, and thus just leave it as text.
We had some tight deadlines, and ultimately chose the binary i/o. But we kept the text i/o simply to test.
Good luck.
PS - we eventually added a 'version' number for the contents of store/restore, to support struct changes during evolution of the project code.