Answer 1

Usually you have a problem if you are using strings and want to save and load them to and from a binary file because a string doesn't have a defined size. So c++ doesn't actually know how many bits it should read back in. Not sure tho if thats causing the problem here and why it would even work then. Would need to check this in a debugger.

Answer 2

Probably because writing a string member to a bin is not correct..
It's a serialization problem.

That said, when an object is destroyed, STL members are automatically destroyed too..
And you probably saved the string object data and not the data contained(the text)
So when you deleted the first object you also called the destructor of the string of the original object.
When the original object is destroyed the string is already destroyed => call destructor of unallocated memory == UB ==> The program crash!

Using a char buffer solved the problem.
If you want to keep using a string member(or a vector,a map ...) you have to define a write and read method inside your class to serialize the data.

Answer 3

Strange. The number of objects destroyed seems to match the number of calls to new. Maybe a coincidence?

delete reader2;
//delete [] reader;
delete &reader[0];
delete &reader[1];
delete &reader[2];

Even explicitly trying to destroy all 3 objects in the array as above makes no change.

Answer 4

I'll try to solve tomorrow. I must go off. Interesting though