![]() |
Stadard C i/o problems with C++ classes
I am trying to write some code that saves the contents of a C++ class in a file. So, I am experimenting with some C and C++ i/o code, but I am stuck in some things...
Lets say I have the following code: :
The error I get when I run this code is: :
SoulFramework(1211) malloc: *** Deallocation of a pointer not malloced: 0x3007d0; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debugHowever, if I use character arrays or something like integers in the struct, the code works just fine. 1)Why? Does that have something to do with classes like std::string and vector that are dynamic? 2)If I definitely want to use those classes with standard C i/o what should I do? 3)If I decide to use C++ i/o, what can I do to store the elements of a class like a vector<customStruct> inside a file? The contents of the customStruct could be integers, floats, or std::strings. EDIT: To make myself clear: I have a class, that occupies some memory. Is there any way to save this memory piece into a (binary?) file and then load it the same way? I suppose the file would be unreadable by a text editor, this way. |
Don't mix new with free. Free is for use with malloc. Delete is for use with new.
I would use C++ file I/O and write a serialize method for the class (overload the << operator, for instance). |
Quote:
But as stupid as it may sound, my question remains. Why am I getting these errors? As for your solution... Do you mean I should write a class, overload the << operator for this class and output the result in a stream? Ok, let's say I do this, how do I read them back from the file? Using the >> operator in the same order I have written the data in the first place? |
1) You're getting the errors (the only ones you mention in your post) because the pointer returned by new is not a valid pointer for free. Again, use delete.
2) Yup. The problem with writing the structure out en masse is that padding bytes may or may not be present with different compilers run on different systems. It's a portability issue. |
Thanks a lot, Dawei. But:
Quote:
:
Result: :
[Session started at 2007-07-14 12:58:33 +0300.]Maybe I'm missing something... I think I mentioned that using 'delete' has the same result. |
The vector in kkk holds strings allocated on the heap, which are referred by pointers. What you are storing in the file are the pointers. When you delete kkk, you are deleting the information. The pointers become invalid. When you read the file, you put these invalid pointers in lll. When they get dereferenced during the cout, el puko on el shoes.
|
I see. Thanks Dawei, it makes much more sense now. Seems to me that the best method is to use classes with overloaded operators to do the hard work.
|
Yeah. It's a matter of shallow copy versus deep copy. You'd have the same problem if you instantiated lll and assigned kkk to it. When kkk went away, it'd be bogus. You'd need to write a copy constructor and make a deep copy.
|
Yup; it's an issue of deep versus shallow copy.
Another description is that use of fread()/fwrite() and C++ classes often don't mix. A common case where they definitely don't mix are when the C++ classes involved have a non-default copy constructor (which allocate resources, etc). Your TestStruct contains two std::strings and a vector of std::strings, which means it contains multiple objects with non-default copy constructors (std::string has a non-default copy constructor, and std::vector<anything> has a non-default copy constructor, as both strings and vectors dynamically manage memory). Non-default copy constructors, in practice, are usually associated with non-default assignment operators. If you write such objects out with fwrite() and read them in again with fread(), then you are unlikely to get the original object back in good shape. The error messages about no deallocation of malloc()'ed memory is one potential consequence of that. |
| All times are GMT -5. The time now is 2:47 AM. |
Powered by vBulletin® Version 3.7.0, Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Copyright ©2007 DaniWeb® LLC