What mechanisms for data-persistence (saving program state) is available in C++?
I would like my programs to store and resume execution state (which may consist of reference/value-type variable values and data structure values).
I believe what I need is a library to serialize program data so that it can be written out to and restored from a file. In Python, I've used the Pickle module to serialize, store/load data to/from a pickle file and it worked well.
But I wonder what mechanism is used by enterprise software. In your experience, have you seen many programs that save state data in between executions? How do they do it?
I'd imagine it'd be useful: Caching solutions to long-running/time consuming computations, loading user data & settings, resuming a task where you left off if your system fails unexpectedly.
I believe what I need is a library to serialize program data so that it can be written out to and restored from a file. In Python, I've used the Pickle module to serialize, store/load data to/from a pickle file and it worked well.
But I wonder what mechanism is used by enterprise software. In your experience, have you seen many programs that save state data in between executions? How do they do it?
I'd imagine it'd be useful: Caching solutions to long-running/time consuming computations, loading user data & settings, resuming a task where you left off if your system fails unexpectedly.
Last edited on
writing to a file is the primary one. Windows has a registry that is really a file but acts like half a database, and you also have environment variables (clunky and archaic, IMHO). Windows in particular has a very limited environment and over-doing it causes major malfunctions that the user has to fix by hand (the amount of text you can store here is too small so 4 or 5 old programs that dump a lot of env text will overflow it and break stuff).
you don't generally need libraries to read and write these files. Grab the raw bytes and write them. You also need the same kind of code to send over a network (serialize and reverse it). C++ containers are very friendly to serialization; the only thing you really need to deal with is to handle pointers. That is, say you had a vector of <yourclass> which has a string. You can't just write the raw bytes of the vector, because the string has put the actual text outside that block of memory via a pointer :(. You have to write a function that gets the string.c_str and length() and write that block of bytes (padding or truncating to a fixed size for 'binary' files), which you can do by writing a self-serialize member function in the class that rolls out what you need.
what I tend to do, and it may not be the *bestest mostest OOP uber c++ design way*, is to design up front what needs to be written to a file or network and make that a base class (really, a base C struct) that can just be written directly without any extra work being done. If you can't manage that (it is not good for complicated designs, but I do a lot of simple data manipulation) you will instead prefer to write a method that extracts the data into the file piece by piece. You can use an intermediate struct for small data, but that is an extra copy that may or may not make sense to do (usually, not).
one of our real time programs logged everything it did, you could actually replay every user command and everything the system did for post-mortem diagnostics. We only used it twice that I recall, but it was a lifesaver for finding out what actually happened.
you don't generally need libraries to read and write these files. Grab the raw bytes and write them. You also need the same kind of code to send over a network (serialize and reverse it). C++ containers are very friendly to serialization; the only thing you really need to deal with is to handle pointers. That is, say you had a vector of <yourclass> which has a string. You can't just write the raw bytes of the vector, because the string has put the actual text outside that block of memory via a pointer :(. You have to write a function that gets the string.c_str and length() and write that block of bytes (padding or truncating to a fixed size for 'binary' files), which you can do by writing a self-serialize member function in the class that rolls out what you need.
what I tend to do, and it may not be the *bestest mostest OOP uber c++ design way*, is to design up front what needs to be written to a file or network and make that a base class (really, a base C struct) that can just be written directly without any extra work being done. If you can't manage that (it is not good for complicated designs, but I do a lot of simple data manipulation) you will instead prefer to write a method that extracts the data into the file piece by piece. You can use an intermediate struct for small data, but that is an extra copy that may or may not make sense to do (usually, not).
one of our real time programs logged everything it did, you could actually replay every user command and everything the system did for post-mortem diagnostics. We only used it twice that I recall, but it was a lifesaver for finding out what actually happened.
Last edited on
| I would like my programs to store and resume execution state |
Our products support full Undo/Redo so our application is actually driven by a set of command classes that the user (unknowingly) initiates via/mouse/keyboard. We serialise these for crash recovery and/or playback. This method provides an "incremental" record, ie; all the changes made, in chronological order. Its nice to have when a customer experiences a problem, we can replay their activities to (hopefully) see where the program went wrong, so double whammy, debug replay for us and undo/redo for the customer.
The other method that i've used with previous employers is a "snapshot" method, where the program state was saved after each action, not so good for big applications but no so heavy code required either so perhaps more suitable to smaller apps or apps with no undo/redo feature, swings and roundabouts i feel.
Topic archived. No new replies allowed.