Saving data from derived class in map

[1yvXoG1T]

I have a map of a base class and I'm using it to save all of the instances of the derived classes. When I use it specifying the derived class as the map then it works fine but when I run it using the base class I get a seg fault.

/*************************
 *  This one works fine  *
 *************************/
map<int, Apple*> FruitMap;

/** Stuff for filling the map etc. **/

fstream fout(filename, ios::out|ios::binary);
for(it = FruitMap.begin(); it != FruitMap; it++)
     fout.write(reinterpret_cast<char*>(it->second->weight), sizeof(int); // Assume weight is a variable of an Fruit object 

/****************************
 *  This one doesn't  *
 ****************************/
map<int, Fruit*> FruitMap;

/** Stuff for filling the map etc. **/

fstream fout(filename, ios::out|ios::binary);
for(it = FruitMap.begin(); it != FruitMap; it++)
     fout.write(reinterpret_cast<char*>(it->second->weight), sizeof(int); // Assume weight is a variable of an Fruit object 

Suggestions?

[jsmith]

What you are doing is very bad... you cannot memcpy objects that contain virtual functions. (Which is what you are effectively doing).

Technically speaking, the standard doesn't allow you to do this the moment you add any constructor, destructor, or method, virtual or not, to the class, but most people conveniently ignore that little detail.

(Hint: there are very few good uses of reinterpret_cast)

[1yvXoG1T]

I actually was not aware of that. What would you suggest for this situation? Because I'm going to have a lot of derived classes and it would be quite a pain to write a manager for each, individual, class.

[Disch]

Wait... I don't see what's so wrong in what he's doing. Or was his post edited to remove the bad part?

[xephon]

r u implementing Fruit as an interface? from your posting that's the idea i get.

anyway, i don't see what's so wrong either. it appears to me that there's no memcpy involved.

there is one question though. assume that i have an interface and several classes implementing it. can i use the interface name or the class names as a feasible type? i know in java, you should be able to do this. not sure how this works out in C++.

[1yvXoG1T]

@Disch - The code hasn't been altered. I edited it because I made a few typoes in the code
@xephon - I'm a little confused because C++ doesn't actually support an "interface." I'm sure you could write something with similar functionality in mind but C++ doesn't natively support that concept.

EDIT: I've tried to isolate the issue and it seems that my fstream won't write out ANYTHING, including constant values, at this point.

std::fstream fout(filename.c_str(), ios::out|ios::binary|ios::trunc);
    if(!fout) {
        std::cout << "Error: could not load file to save to.";
        exit(1);
    }

    fout.write(reinterpret_cast<char*>(8), sizeof(int));

Output:
SIGSEV

One more note: This is inside of a singleton class

[firedraco]

If you want to write an interface, simple inherit publicly from a class with only pure virtual functions.

Anyway, line 7 is very bad, you are basically telling the program to "Go to memory address 0x8 and write whatever is there as an int", which obviously the OS didn't let you.

If you want to write a number you'd have to do something like this:

int x = 8;
fout.write(reinterpret_cast<char*>(&x), sizeof(int));

[1yvXoG1T]

Oh, derp, my mistake. That's what I get for trying to debug five minutes before class ><

Regardless of that, I still cannot get it to write out the contents of my map. At least not as long as I'm using the base class for the map.

[jsmith]

@Disch
@xephon

I assumed OP wanted to write the binary contents of the object (Fruit) to file based on the comments on line 10, however the code as written doesn't compile, so I can't be sure.
Effectively that is a memcpy where the destination is the disk.

[kbw]

http://www.cplusplus.com/forum/general/28873/

[1yvXoG1T]

@kbw - Oh wow, this shines quite a light on the situation. Looks like I've got a little bit of work ahead of me but it should be up and running soon.

Thanks to everyone who contributed :D