[crossfire] useful macros in crossfire

[Mark Wedel]

Alex Schultz wrote:
> Often when looking through code, I notice that that many code snippets
> are repeated in many places, often with variations on how to do the same
> task. The best example is iterating through stacks of objects, because
> loops for that are implemented in many different places, with quite a
> few needless variations. Another example is "if ob->head ob=ob->head;"
> while not complex, might be more readable as something like "ob =
> GET_HEAD(ob);". I propose that we add the following macros or similar to
> the crossfire code to make things cleaner:

  Generally speaking, just because the code is repeated, it isn't necessarily 
bad if the the expanded code isn't very long, is clear to understand, and is 
unlikely to need global replacement because of some other change in the the code.

  OTOH, I'm pretty use to the code, so when I see most of those operations, it 
is pretty clear to me what it is doing.

  I'm more inclined to accept the GET_.. ones than the TRANSVERSE ones.  They 
seem cleaner - maybe it is just me, but having something like:

   TRANSVERSE_INV() {
   }

  seem a bit more confusing to me, as it is actually hiding the operation from 
you, which may be relevant depending on what you do in that inner loop.  That 
could perhaps be improved by calling them something like FOREACH, which better 
describes what it is doing.

  But also, I think that several of the TRANSVERSE macros as is will have 
problems, as I know there is code like:

  for (tmp=ob->inv; tmp && next; tmp=next ) {
	next = tmp->below
  }

  Because depending on operations, you can't rely on tmp->below to be accurate 
after doing remove_ob or insert_ob calls.  This is true for both inventory and 
map loops.  So that now needs another set of macros to take that third object 
pointer.

  To me, going through the code and updating all those code snippets would be 
near the bottom of the list of things to do, given the fairly long TODO list 
that there currently is (and given that the this doesn't effectively change the 
operation of any of the code, it just changes how it looks).  But making the 
macros available and used in new code may not be a bad thing.