I need to create a function that undoes the previous task/addition/change. How do I do this in Borland C++?
(The program stores strings of text in a text file using "list". It is stored and then erased unless I use the save-function I've created.)
I meant creating an undo function in a simple console application by the way.
I'll give yet another answer, but I think that the coverage has been insufficient so far.
The subject is far from trivial, and googling it returns a good number of results. Many applications implement a "undo" operation, and there are many variants.
There are 2 design patterns which can help us out here:
Command: it's a reification of an action
Memento: which consists in storing state (usually implies some form of serialization)
The Command pattern is heavily used in graphic environments because there is usually various ways to accomplish an action. Think of save in Microsoft Word for example:
you can click on the save icon
you can go into File menu and click on Save
you use the shortcut, typically CTRL+S
And of course save is probably implemented in term of save as.
The advantage of the Command pattern here is twofold:
you can create a stack of objects
you can ask every object to implement an undo operation
Now, there are various issues proper to undo:
some operations cannot be undone (for example, consider rm on Linux or the empty trash bin action on Windows)
some operations are difficult to undo, or it may not be natural (you need to store some state, the object is normally destroyed but here you would need to actually store it within the command for the undo action)
generally we think of undo/redo as a stack, some software (graphics mainly) propose to undo items without actually undoing what has been done afterward, this is much more difficult to achieve, especially when the newer actions have been built on top of the to-undo one...
Because there are various problems, there are various strategies:
For a simple Command, you might consider implementing an undo (for example, adding a character can be undone by removing it)
For a more complex Command, you might consider implementing the undo as restoring the previous state (that's where Memento kick in)
If you have lots of complex Command, that could mean lots of Mementos which consumes space, you can then use an approach which consists in only memorizing one Snapshot every 10 or 20 commands, and then redoing the commands from the latest snapshot up to the undone command
In fact, you can probably mix Command and Memento at leisure, depending on the specifics of your system and thus the complexity of either.
I would only considering undoing the last action executed to begin with (using a stack of action then). The functionality of undoing whatever action the user wishes is much more complicated.
To implement Undo, you need to create an "action stack" in your application. There are two basic approaches, though:
Knowing your baseline (the last time the file was saved, or since the file was created), remember every single change that was made so that when something needs to be undone you just throw away the "top-most" item and regenerate the current view from the baseline plus all of the changes. Clicking "Redo" then just puts that item back on the stack. This has a side benefit of being able to trivially remove items anywhere in the stack without messing up other undo/redo options, although there will be special care needed to make sure that the application of "higher" states is as the user intended.
For each action, store off the change that was made to the previous state as well as the change that would be necessary to restore that previous state if you were to undo. Now when the user clicks "Undo," just do the "undo" steps. When clicking "Redo," reapply the changes that were made. In some cases the "Undo" steps will be "here's what the thing looked like before," but that can cause havoc if you want to allow users to remove items that are not on the top of the stack and then need to remove something above it.
The proper choice depends on a lot of factors, including how much data you can/will carry around. Option #1 is in some sense easier but it could become very slow to undo anything if the action stack is large.
You should check out Command Pattern.
Another reference: Using the Command pattern for undo functionality
Also see the memento pattern. Sometimes the intelligence that must go into a command to undo an operation is pretty involved. Drawing objects in a paint program for example. It can be easier just to store a memento and then restore from that memento to implement undo.
You can store snapshots of state. State is the set of data that an action can modify. When you click undo, the current state is replaced by previous. Actually it is not a trivial task, especially if the state is complex.
I've been experimenting lately on that subject. In case you don't need binary compatibility, check out https://github.com/d-led/undoredo-cpp
Related
I have a mapping in my application that must be maintained for every line.
When the user deletes a line, I'm trying to detect which line so I can update my mapping.
The contentsChange signal has where in the document a change occurred and how many characters are added or deleted, but at this point it's too late to determine what was there before the delete.
So far here's what I've been thinking about trying:
If I peek at the undo stack maybe I can get at the lines that were deleted, but this may not be reliably for large change blocks.
I could keep a previous state of the file for every change, and then try to look there when the signal is raised, but this seems like a lot of unnecessary overhead.
I could try to dig into the source and create a new signal before something is about to be deleted, but then I have to build my code and release this modification since I'm using LGPL.
I can put consecutive values in userState in every block and if when contentsChanged is fired, and I detect a gap in the consecutive values between the previous and next block from where the change occurs, I can infer the deleted blocks. The downside here is that I have to then update all of the remaining blocks after I detect a change to restore the consecutive values.
What's the most graceful (simplest and inexpensive) way to do this?
I'm using Qt5.2.1 with c++.
Edit:
I'm trying a major redesign of my application by putting more of my custom info in the user state directly in the block (per line since I don't have word wrap). If I can get by with this approach, it will avoid the problem of having detect when a line is deleted all together, but the problem is still an interesting one and I think it still begs for an an answer.
In other GUI frameworks, the operation stack that fed the undo stack had pre-change callbacks, and post-change callbacks. I think the pre-change callback is what's missing here. Or is there some better way I don't know about???
Basically as part of a team I have had to create a pacman like game for my university course, just zombies instead of ghosts.
We have built all of the game so far and it seems to work really well. Our current problem is that we have to Save a game (with a username and score), Load the game into the position it was once saved, with the correct username and score, and finally be able to offer a replay option where the user can see all the moves that they have previously made (as well as the moves the zombies have made). The zombies will always make the same moves that the user makes as they are designed to chase the user.
My question is what would be the best way to do the save, load and reload options? We cannot use vectors, stacks or queues. We can only really use strings, arrays and other basic variables.
We were thinking to do the reload first by adding everything onto the end of a string and then popping the last value off the string. We could then delay each one by a second and the user will be able to see his/her moves.
As for Saving we were unsure, there are also holes (0 symbols) and pills (* symbols) to take into account. So the position of character, zombies, pills and holes will need to be saved. The character can start from any random position and pretty much everything else is placed after.
The way we do the loading will depend on the way you suggest we do the saving.
Does anyone have any suggestions of the way we should do save, load and replay?
thanks
The simplest way I could think of is saving the user inputs.
This way you could easily replay the game by sending the inputs to the game engine (this may require a lot of restructuring depending on the design of the game engine). To accelerate the loading you could also save the game state at the time of the save (through serialization).
That's the idea, how to do it... you need an ever-expanding array to record the user-input, so let's use a linked-list.
struct Node {
T data;
Node* next_node;
};
//Google for the rest of the code, it is a reeeaaallly
// basic/fundamental data structure.
The data would be the user-inputs and the time they happened.
To save the data, you simply have to iterate through the linked-list and append it to a std::ostream& (to be generic, a std::ofstream& to be specific).
You may add some other useful information (such as the game state and the highscore) before or after the user inputs (or even in another file, which would really make sense for the highscores).
You'll need to read up on some serialization. I wrote some articles on it here, but this is going to be overkill for you guys: http://www.randygaul.net/2013/01/05/c-reflection-part-5-automated-serialization/
You can use some very simple serialization to write out the moves of each zombie into a file. Then when you want to reload this information you deserialize the information in the file. Each move will likely be stored in some form of a linked list so you'll have to come up with a way of recreating such lists upon deserialization.
Your question is really broad so my answer has to be quite broad as well. Really it's up to you to research a solution and implement it.
for quite some time I've been working on an application. As programming is just a hobby this project is already taking way too long, but that's besides the point. I'm now at a point where every "problem" becomes terribly difficult to solve. And I'm thinking of refactoring the code, however that would result in a "complete" rewrite.
Let me explain the problem, and how I solved it currently. Basically I have data, and I let things to happen over this data (well I described about every program didn't I?). What happens is:
Data -> asks viewer to display -> viewer displays data based on actual data
viewer returns user input -> data -> asks "executor" to execute it -> new data
Now this used to work very well, and I was thinking originally "hey I might for example change command prompt by qt, or windows - or even take that external (C#) and simply call this program".
However as the program grew it became more and more tiresome. As the most important thing is that the data is displayed in different manners depending on what the data is and -more importantly- where it is located. So I went back to the tree & added someway to "track" what the parent-line is". Then the general viewer would search for the most specific actual widget.
It uses has a list with [location; widget] values, and finds the best matching location.
The problems starts when updating for new "data" - I have to go through all the assets - viewer, saver etc etc. Updating the check-mechanism gave me a lot of errors.. Things like "hey why is it displaying the wrong widget now again?".
Now I can completely swap this around. And instead of the tree datastructure calling to a generic viewer. I would use OO "internal" tree capabilities. The nodes would be childs (& when a new viewer or save-mechanism is needed a new child is formed).
This would remove the difficult checking mechanism, where I check the location in the tree. However it might open up a whole other can of worms.
And I'd like some comments on this? Should I keep the viewer completely separate - having difficulty checking for data? Or is the new approach better, yet it combines data & execution into a single node. (So if I wish to change from qt to say cli/C# it becomes almost impossible)
What method should I pursue in the end? Also is there something else I can do? To keep the viewer separate, yet prevent having to do checks to see what widget should be displayed?
EDIT, just to show some "code" and how my program works. Not sure if this is any good as I said already it has become quite a clusterfuck of methodologies.
It is meant to merge several "gamemaker projects" together (as GM:studio strangely lacks that feature). Gamemaker project files are simply sets of xml-files. (Main xml file with only links to other xml files, and an xml file for each resource -object, sprite, sound, room etc-). However there are some 'quirks' which make it not really possible to read with something like boost property trees or qt: 1) order of attributes/child nodes is very important at certain parts of the files. and 2) white space is often ignored however at other points it is very important to preserve it.
That being said there are also a lot of points where the node is exactly the same.. Like how a background can have <width>200</width> and a room too can have that. Yet for the user it is quite important which width he is talking about.
Anyways, so the "general viewer" (AskGUIFn) has the following typedefs to handle this:
typedef int (AskGUIFn::*MemberFn)(const GMProject::pTree& tOut, const GMProject::pTree& tIn, int) const;
typedef std::vector<std::pair<boost::regex, MemberFn> > DisplaySubMap_Ty;
typedef std::map<RESOURCE_TYPES, std::pair<DisplaySubMap_Ty, MemberFn> > DisplayMap_Ty;
Where "GMProject::pTree" is a tree node, RESOURCE_TYPES is an constant to keep track in what kind of resource I am at the moment (sprite, object etc). The "memberFn" will here simply be something that loads a widget. (Though AskGUIFn is not the only general viewer of course, this one is only opened if other "automatic" -overwrite, skip, rename- handlers have failed).
Now to show how these maps are initialized (everything in namespace "MW" is a qt widget):
AskGUIFn::DisplayMap_Ty AskGUIFn::DisplayFunctionMap_INIT() {
DisplayMap_Ty t;
DisplaySubMap_Ty tmp;
tmp.push_back(std::pair<boost::regex, AskGUIFn::MemberFn> (boost::regex("^instances "), &AskGUIFn::ExecuteFn<MW::RoomInstanceDialog>));
tmp.push_back(std::pair<boost::regex, AskGUIFn::MemberFn> (boost::regex("^code $"), &AskGUIFn::ExecuteFn<MW::RoomStringDialog>));
tmp.push_back(std::pair<boost::regex, AskGUIFn::MemberFn> (boost::regex("^(isometric|persistent|showcolour|enableViews|clearViewBackground) $"), &AskGUIFn::ExecuteFn<MW::ResourceBoolDialog>));
//etc etc etc
t[RT_ROOM] = std::pair<DisplaySubMap_Ty, MemberFn> (tmp, &AskGUIFn::ExecuteFn<MW::RoomStdDialog>);
tmp.clear();
//repeat above
t[RT_SPRITE] = std::pair<DisplaySubMap_Ty, MemberFn>(tmp, &AskGUIFn::ExecuteFn<MW::RoomStdDialog>);
//for each resource type.
Then when the tree datastructure tells the general viewer it wishes to be displayed the viewer executes the following function:
AskGUIFn::MemberFn AskGUIFn::FindFirstMatch() const {
auto map_loc(DisplayFunctionMap.find(res_type));
if (map_loc != DisplayFunctionMap.end()) {
std::string stack(CallStackSerialize());
for (auto iter(map_loc->second.first.begin()); iter != map_loc->second.first.end(); ++iter) {
if (boost::regex_search(stack, iter->first)) {
return iter->second;
}
}
return map_loc->second.second;
}
return BackupScreen;
}
And this is where the problems began to be frank. The CallStackSerialize() function depends on a call-stack.. However that call_stack is stored inside a "handler". I stored it there because everything starts FROM a handler. I'm not really sure where I ought to store this "call_stack". Introduce another object that keeps track of what's going on?
I tried going the route where I store the parent with the node itself. (Preventing the need for a call-stack). However that didn't go as well as I wished: each node simply has a vector containing its child nodes. So using pointers is out of the question to point to the parent note...
(PS: maybe I should reform this in another question..)
Refactoring/rewriting this complicated location checking mechanism out of the viewer into a dedicated class makes sense, so you can improve your solution without affecting the rest of your program. Lets call this NodeToWidgetMap.
Architecture
Seems your heading towards a Model-View-Controller architecture which is a good thing IMO. Your tree structure and its nodes are the models, where as the viewer and the "widgets" are views, and the logic selecting widgets depending on the node would be part of a controller.
The main question remains when and how you choose the widget wN for a given node N and how to store this choice.
NodeToWidgetMap: When to choose
If you can assume that wN does not change during its lifetime even though nodes are moved, you could choose it right when creating the node . Otherwise you'll need to know the location (or path through the XML) and, in consequence, find the parent of a node when requesting it.
Finding Parent Nodes
My solution would be to store pointers to instead of the node instances themselves, perhaps using boost::shared_ptr. This has drawbacks, for example copying nodes forces you to implement your own copy-constructors that uses recursion to create a deep-copy of your sub-tree. (Moving however will not affect the child nodes.)
Alternatives exist, such as keeping child nodes uptodate whenever touching the parent node respective the grandfathers vector. Or you can define a Node::findParentOf(node) function knowing that certain nodes can only (or frequently) be found as child of certain nodes. This is brute but will work reasonably well for small trees, just does not scale very well.
NodeToWidgetMap: How to choose
Try writing down the rules how to choose wN on piece of paper, perhaps just partially. Then try to translate these rules into C++. This might slightly longer in terms of code but will be easier to understand and maintain.
Your current approach is to use regular expressions for matching the XML path (stack).
My idea would be to create a lookup graph whose edges are labelled by the XML element names and whose nodes indicate which widget shall be used. This way your XML path (stack) describes a route through the graph. Then the question becomes whether to explicitly model a graph or whether a group of function calls could be used to mirror this graph.
NodeToWidgetMap: Where to store choice
Associating a unique, numeric id to each node, record the widget choice using a map from node id to widget inside the NodeToWidgetMap.
Rewriting vs Refactoring
If you rewrite you might get good leverage tieing to an existing framework such as Qt in order to focus on your program instead of rewriting the wheels. It can be easier to port a well-written program from on framework to another than to abstract around the pecularities of each platform. Qt is a nice framework for gaining experience and good understanding of the MVC-architectures.
A complete rewrite gives you a chance to rethink everything but implies the risk that you start from scratch and will be without a new version for a good amount of time. And who knows whether you will have enough time to finish? If you choose to refactor the existing structures you will improve it step by step, having a useable version after each step. But there is small risk to remain trapped in old ways of thinking, where as rewriting nearly forces you to rethink everything. So both approaches have their merits, if you enjoy programming I would rewrite. More programming, more joy.
Welcome to the world of programming!
What you describe is the typical life cycle of an application, starts as a small simple app, then it gets more and more features until it is no longer maintainable. You can't imagine how many projects I've seen in this last collapsing phase!
Do you need to refactor? Of course you do! All the time! Do you need to rewrite everything? Not so sure.
In fact the good solution is to work by cycles: you design what you need to code, you code it, you need more functionality, you design this new functionality, you refactor the code so you can integrate the new code, etc. If you don't do it like this then you will arrive to the point where its less expensive to rewrite then to refactor. Get this book: Refactoring - Martin Fowler. If you like it then get this one: Refactoring to Patterns.
As Pedro NF said, Martin Fowler "Refactoring" is the nice place to get familiar with it.
I recommend buying a copy of Robert Martins "Agile Principles, Patterns and Practices in C#" He goes over some very practical case studies that show how to overcome maintenance problems like this.
I'm looking for a good efficient method for scanning a directory structure for changed files in Windows XP+. Something like how git does it is exactly what I'm looking for, when running a git status it displays all modified files, all new (untracked) files and deleted files very quickly which is exactly what I would like to do.
I have a basic model up and running which performs an initial scan and stores all filenames, size, dates and attributes.
On a subsequent scan it checks if the size, attributes or date have changed and marks as a changed file.
My issue now comes in detecting moved and deleted files. Is there a tried and tested method for this sort of thing? I'm struggling to come up with a good method.
I should mention that it will eventually use ReadDirectoryChangesW to monitor files and alert the user when something changes so a full scan is really a last resort after the initial scan.
Thanks,
J
EDIT: I think I may have described the problem badly. The issue I'm facing is not so much detecting the changes - I have ReadDirectoryChangesW() using IOCP on multiple threads to detected when a change happens, the issue is more what to do with the information. For example, a moved file is reported as a delete followed by a create and a rename comes in 2 parts, old name, followed by new name. So what I'm asking is how to differentiate between the delete as part of a move and an actual delete. I'm guessing buffering the changes and processing batches would be an option but feels messy.
In native code FileSystemWatcher is replaced by ReadDirectoryChangesW. Using this properly is not simple, there is a good baseline to build off here.
I have used this code in a previous job and it worked pretty well. The Win32 API itself (and FileSystemWatcher) are prone to problems that are described in the docs and also discussed in various places online, but impact of those will depending on your use cases.
EDIT: the exact change is indicated in the FILE_NOTIFY_INFORMATION structure that you get back - adds, removals, rename data including old and new name.
I voted Liviu M. up. However, another option if you don't want to use the .NET framework for some reason, would be to use the basic Win32 API call FindFirstChangeNotification.
You can use USN journaling if you are up to it, that is pretty low level (NTFS level) stuff.
Here you can find detailed information and source code included. It is written in C# but most of it is PInvoking C/C++ functions.
I'm trying to write an editor overtop a multi-threaded game engine. In theory, through the editor, the contents of the scene can be totally changed but I haven't been able to come up with a good way for the engine to cope with the changes. (ie delete an entity while the renderer was drawing it). Additionally, I'm hesitant to write code to manage locks at every instance I use an entity or resource that can be potentially deleted. I imagine there has to be a relatively more elegant solution.
Does anyone have any ideas or strategies I can start looking at?
Thanks!
In addition to the two-stage process suggested by #lassevk you could use a Pipe structure to "push" commands to the renderer so that these changes gets the form of another work item for the render engine.
For example, say your engine follows a workflow like:
Calculate positions
Process Physics
Process Lights Process Cameras
Render Scene
You could just add a new item to the workflow in the position 0, called Process Changes which pulls out the information from the Pipe and incorporates it to the scene.
If memory is not a problem, you can could have a two-stage process, where the changes are done in one model, and then a snapshot is taken for the renderer, this way the renderer would always see a consistent view of the model.
Without knowing your exact need, it is hard for me to comment on the details, but i think if a combination of copy-on-write and lock-free data structure may help.
When you're rendering, you need read only access, so there are no problems. When you're editing, say deleting an object from a group of objects, you mark the current object "deleted" using atomic operations and your renderer can skip or remove the object before the next render loop. When an object is changed, you make a copy and change the copy and "commit" the change using lock-free techniques.