Hi Stefan!
Well you could implement it like this (if that works, didn't test it yet).
Although you would still need a wrapping undo_list class, to implement all
the undo/redo-relationship, the checks "is the undo-vector already empty"
etc., basically everything that's in my undo_list class already (at there
are quite a few bits). So in fact one would change the storage members and
change the interface for the user.
Instead of writing undo-classes with a constructor, an undo-function and a
redo-function (that makes 3) one would have to write two functions, that
take the appropriate parameters (so speaking in numbers, you would save 1
function).
BUT, when executing the undo-code one might want to add a redo-function to
the redo list and all shared properties/member-variables have to be copied
yourself:
void string_erase_undo(std::string& dest, int pos, std::string to_insert) {
dest.insert(pos, to_insert);
// now add the redo function
redolist.push_back(boost::bind(string_erase_redo, dest, pos,
to_insert(size)));
// questions: 1. What is redolist? does every undo/redo-function need to
know this?
// 2. Do I really have to copy all the function parameters?
// 3. Why do I (the undo function) have to add the redo
function? This is
// multiplying the same code (in every undo and redo
function)
}
Ok, there you see some of the problems/disadvantages of this approach.
Well, there's another minor advantage of my solution. You wouldn't be
obliged to use other libraries (even though this are boost library
elements).
Thinking it over I came to the conclusion that the derived-undo_action-class
version is the most convenient and most flexible way of doing so... but
there's surely something I forgot to think of!?
Bye - Andreas
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
