Question about char pointers and random binary files

Hey guys, so I'm new with working with random binary files, and I have a couple of questions of why certain things work...or at least look like they are working:

I have a class with a char* pointer stored inside of it, I also have a constructor that takes in a string (of any size) from the user. I then simply store this string into the char *. Once the string is stored in the char *. I reinterpret the instance, and I store the information into the random binary file. Everything works.

Question: Random files must know the size of the object that is being stored inside of it, so why when I enter strings of different sizes into the file, it appears to still be working. for example this is an example of the code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
//This is just a quick example of the code  I'm using to give a visual of what
//I'm trying to explain, my code works, this I just wrote,so it may or may not
class info{
private:
	char *phrase;
public:
	info(string n ="unknown"){
	phrase = new char[n.size()+1];
	phrase[n.size()] = '\0';
	memcpy(phrase,n.c_str(),n.size());
	}
	void setPhrase(string n){
		phrase = new char[n.size()+1];
		phrase[n.size()]='\0';
		memcpy(phrase,n.c_str(),n.size());
		
	}
	string getPhrase(){return phrase;};
};


int main(){
info objOne("abc"),objTwo("laksdflkjdsalf"),objETC(...);

//some code

fileVariable.write(reinterpret_cast<const char*>(&objOne),sizeof(info));
fileVariable.write(reinterpret_cast<const char*>(&objTwo),sizeof(info));
fileVariable.write(reinterpret_cast<const char*>(&objETC),sizeof(info));

}


my point is, lets just say for example the object ETC, was some long string, this would still work for me. My question is, I don't believe each object is the same size because I allocate memory for the char pointer in the constructor.

Should I not do this just to be safe, and just use a char array instead of a pointer?
(Even tho I would have set a pre-defined size for the string)

or is something happening in the back to prevent this from not working?
Thanks
Last edited on
Are you sure this code works?
If fileVariable is an ostream object I suspect it doesn't work because you're writing out the address of the string each info object contains and not the string text itself.

You should probably instead do:

fileVariable.write(objOne.getPhrase().c_str(), objOne.getPhrase().size()+1);

or better still add a method to info which writes it to ostream.
That way if you needed to change info later you could just update that method instead of having to update all code where info is written.

Using a pointer for phrase is better because it is more flexible but don't forget to delete it in a destructor and in setPhrase
Hey,
Plover
Are you sure this code works?


Yeah, I'm 100% my code works in VS2013, the code I have above, is just example/visual of what the code does, and it doesn't take the string and send the string to the file, it is sending the object to the file, everything within it. So in my program there isn't just a char* there other datatypes that are also sent to the file as well.

The issue isn't one of "how to get it to work" but one of "Why is it working?" I mean if you look at my code, it writes everything to the file, but it seems that the size doesn't matter, it still works regardless.
So if you open the file produced by the program all the strings you wrote appear in the file?
And if you copy the file and the executable to another computer it is able to read all the objects back in correctly?
If you just write an object and then immediately after read it back it may appear to work because the memory pointed to still contains the strings. In fact it is supposed to if you didn't delete them in the meantime and even if you delete them it still might because the OS might not reuse that memory straight away.
Not an answer to your question, but: what exactly are random binary files used for? For example? (wondering if I would ever use it, somehow)

do I get it right that it might have something to do with encrypting, at least in this case?
Topic archived. No new replies allowed.