Thread: Serializing classes

Originally Posted by Whyrusleeping

also, in your rewritten search function, what happens when the word being searched for isnt in the file? it looks like an infinite loop

So it is. A bug.
I edited the original code to fix the bug.
We have to manually check for eof. Using eof as loop control is a bad idea™ (the faq on the site explain why). Furthermore, what happens if we hit end of file just after reading the length? Another thing not covered by your code.

Originally Posted by King Mir

Of all the things wrong with his code, assuming that int is 4 bytes isn't one that counts. That's a pretty reasonable assumption.

But still an assumption, and assumptions are bad.

Originally Posted by King Mir

Instead of a string or char array, Elysia chose to write the data into a char vector. I presume that this is because std::string data is not guaranteed to be continuous in memory, if that is in fact the case. A vector is like an array, but safer.

The main reason is because I can control its size to make sure there is no buffer overrun. The string's length is not fixed. Plus the OP's original code is prove to buffer overruns because no check is made to ensure the length is < 32.
Although, std::string is not guaranteed to be contiguous, that is of no concern since we're storing a C-style string which is guaranteed to be contiguous and nul-terminated. Similarly, when we read back, it will construct a new string from the C-style string.

Originally Posted by Elysia

So it is. A bug.
I edited the original code to fix the bug.
We have to manually check for eof. Using eof as loop control is a bad idea™ (the faq on the site explain why). Furthermore, what happens if we hit end of file just after reading the length? Another thing not covered by your code.

Your fix demonstrates exactly why checking on eof is not a good idea. If the data is poorly formatted and the length is missing, your program will still loop forever.

But still an assumption, and assumptions are bad.

But it's not a ticking time bomb. It won't fail unless someone tries to compile it on some obscure OS.

The main reason is because I can control its size to make sure there is no buffer overrun. The string's length is not fixed. Plus the OP's original code is prove to buffer overruns because no check is made to ensure the length is < 32.
Although, std::string is not guaranteed to be contiguous, that is of no concern since we're storing a C-style string which is guaranteed to be contiguous and nul-terminated. Similarly, when we read back, it will construct a new string from the C-style string.

std::string has an identical constructor to the one you use for vector. The only reason not to use it is if there is a chance that &buf[0] doesn't correctly access the entire string.

I don't know if string is required to use continuous memory, or if it is allowed to function like deque.

Originally Posted by King Mir

Your fix demonstrates exactly why checking on eof is not a good idea. If the data is poorly formatted and the length is missing, your program will still loop forever.

True, the >> operator is a problematic one.
Still, you know as well as I that using eof for loop control is bad™.

But it's not a ticking time bomb. It won't fail unless someone tries to compile it on some obscure OS.

A bug is a bug, and we specialize in portable code. Thus, if a simple fix can be made, then I say do it.

std::string has an identical constructor to the one you use for vector. The only reason not to use it is if there is a chance that &buf[0] doesn't correctly access the entire string.

I don't know if string is required to use continuous memory, or if it is allowed to function like deque.

This might be a possible optimization, actually...
Still, it was only an example. I would still go with boost to avoid all of this complexity and bug fest.