I was thinking of making a program for fun and I wanted to start working with file read/write.


Some things I want to do:


1: Make a tree to store data. Keeping it simple for now, it will store STRINGS
2: I want the program to check to see if a file exists, and if it has contents, read it into the tree.
3: Make changes to the tree (add/remove shit etc)
4: when done, the program saves the trees contents (preferably in order) to the file.


I know I can print a trees contents using a recursive function, but is it possible to write them as well? Is there something similar to the ECHO command where I could like, ECHO the output of the inorder function to the file? lol


this is all c++ btw. But I guess general ideas wouldn't hurt.

do some google searches for C++ object serialization, and you'll come up with a number of stuff.

as a rule, it's better/easier to store your data in a somewhat unstructured manner and organize your data structure such that it maintains its order invariants as you add/re-add elements to it. unless you have an extremely compelling reason for exporting your tree in a particular order, it's complexity you could really do away with.

so don't worry about writing it in any particular order? I guess that makes sense, since you can define the treeAdd function to do that.

This would be a binary tree btw

edit: I heard there was a tree library for c++ but I can't seem to find any info about it on the c++ resource website

This post was edited by Eep on Nov 9 2012 02:19am

if you're really interested in doing serialization well, look into protocol buffers

what does serialization mean exactly?

wikipedia explains this better than I can
http://en.wikipedia.org/wiki/Serialization

seems cool, but I am not sure if what I want to do is as complicated as what that page defines.

In my last project for example, we made a binary tree and inputted like 200 words and the tree struct kept track of how many instances the word had.

If it is possible to print the contents of a tree of strings, for example, wouldn't it not be much harder to write all those words (and possible their counts) to some file outside of the program?

Serialization comes off to me as a way of storing like, memory/bits etc....they mention storing a STATE but to me a STATE could mean a few things (like storing the location of EVERY SINGLE POINTER in the memory etc OR just the state it is in with regards to WHAT DATA is in it)

instead of trying to wrap your head around how it works under the hood, focus on understanding the concept behind serialization. (abstraction! use it!)

here's a simple example in pseudocode.



The contract for serialize and deserialize here is that the behavior of an object that was serialized to a file should be identical to the behavior of an object that was deserialized from the same file. How it's actually done, whether the pointers are the same, where the state is being stored in memory -- is entirely irrelevant. All that ultimately matters is that the behavior of the methods like doStuff() and doOtherStuff() are consistent.

A simple, real-world analogy is that if I have a car that I drive and I tell you to make another one just like it -- it doesn't matter that you make another one with completely different parts under the hood, with completely different connections. If as the driver of the car, I can't tell the difference between the car you made and the car I have, then it really doesn't matter how the second car was actually built.

Also, remember that if you're the implementer of the serialization/deserialization methods, you have complete control over how it's done. You don't have to replay the 200 words that got inputted in order to build a tree. You could, for example, write your serialization method to simply write out the mappings themselves, but you'd have to make sure that the deserialization code you wrote expects that as the input.

In a lot of ways, the fact that serialization/deserialization ultimately writes to some sort of persistent storage is irrelevant. They're just like any other functions that have contracts that depend on each other. For example, if you had code that looked like this:



It ultimately doesn't matter what you do to get from B to A and to get from A to B. All that matters is that convertBtoA(convertAtoB(someA)) returns an A that is behaviorally identical to someA.

This post was edited by irimi on Nov 9 2012 03:37am

I keep trying to think in terms of c++ (only way I can think atm) so the first thing that came to my mind for what I was thinking originally was the idea of like the libraries ifstream and ofstream.


Are those similar to serialization or different? Or do you know.

Related only in that they deal with files. Similar only in that ifstream and ofstream fulfill similar/dependent contracts.

But conceptually, they're fundamentally different things. ifstream/ofstream is about the process of reading and writing bytes to and from files. Serialization is a much higher-level concept that's interested in the structure of the bytes, rather than just the bytes themselves.