Nicolas Weeger wrote:
>> Now this construct is used to cover the case where the current object
>> (tmp) goes away - we have a pointer to the next object. Such operations
>> are not that uncommon, as the {do some work} block is more likely to
>> destroy tmp.
>
> Actually, you can never be sure any object stays valid, short of restarting
> the loop :)
> Remove is an event a plugin can handle, thus such a plugin could change the
> whole object stack.
>
>
> As for the core of the mail, I guess it's ok to have some shortcut macros for
> common things, but IMO there are too many cases depending on the processing
> you're doing to be able to refactore usefully.
Yes - there are always cases where the code could do something that any macro
can not handle.
But I'd be willing to say that there are a fair number of 'for op->inv do
above' type lists that being able to modify/fix behavior if we discover a
general bug might be desirable.
The problem is I don't see a really clean way to do it. It could be done
with
functions, something like:
while (ob_stack(op->inv, current, next)) {
use current object as expected
}
Might work. Problem is that if a change is needed that requires passing
another parameter in, that now requires updating all those functions.
OTOH, that may be easier, as grep or cscope makes finding all the instances
easy - much more so than trying to find all the for loops. And if ob_stack
(better name needed) is declared as an inline function in object.h or
someplace,
no performance hit. I don't think I'd want that to be a non inline function
because of the performance hit that might result (like was_destroyed() was
before doing performance analysis).
_______________________________________________
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
