Follow-up Comment #11, patch #1020 (project wesnoth):
1) I decided to leave the normal iterators as they are now, since for those
if valid() returns false the iterator is not necessarily invalid, but it
might be... and I didn't want to break any existing code
2) I was unsure of this point, but if I used assert(valid()) then would
valid() still be called if not a debug build? because valid is also used here
to make sure that we are returning the right thing. I only did it that way to
make sure it was called.
3) Yeah, I wasn't sure of the naming... I mean it depends on how these would
actually be used and you definitely would know that better than I.
4) Yes, I tested it, and in fact the patch contains a small change to
formulaAI's unit formulas that uses the unit_iterator in a section of code
that doesn't work with the normal unit_map::iterator (which is why currently
the formulaAI code builds a vector of locations then iterates through that
finding the unit at each as it goes).
So some of my reasoning for the way I implemented the pointer increment:
First, ++iter should always return a valid iterator or the end of the
container. So, we must make those checks.
The reason that I made it dependent on the state of the map when the iterator
is created is so that you iterated over each unit that was in the map at that
point once, and no more, and you only skip a unit if it is no longer in the
unit map (or not in the same location for the unit_by_loc_iterator). To do
that you can't just use a basic iterator since as the underlying map changes
you may end up skipping units or iterating twice over the same unit.
_______________________________________________________
Reply to this item at:
<http://gna.org/patch/?1020>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs
