Oh, recursive functions are very useful, not using them is missing out on a lot. Is some cases you can do the same with a loop, but for things like that flood fill, a loop can't do much.
What? There is precisely nothing that can be done recursively that cannot be done in an iterative manner. Generally speaking, in languages that don't implement tail recursion or do so poorly (Java and .NET don't do so by default), a recursive solution is going to be slower by as much as an order of magnitude
and a recursive solution will require O(n) memory, where n is the number of stack frames used. Scheme and other languages that effectively implement tail recursion will not have the same problem, but then you have to actually be writing your code in those languages.
Recursion is a conceit for the programmer and truly useful in only a relatively small subset of tasks. Programmers who think they understand recursion tend to overuse it, in large part because they do not actually understand it.
The fill works, and I don't really care how fast it does at the moment. If its starts getting really slow with bigger images I might have it work like this, but it looks to complex to implement, at least for a lazy guy like me.
You certainly
should care, because it's wrong and a concern for both security and stability. What happens when you attempt to recursively flood-fill a massive image space? Your program is going to smash the stack.
Generally ++i is faster than i++, since i++ needs to create a copy to return. But only by such a small margin that it's usually not worth the bother, and especially not for built-in types such as int. Otherwise they look much the same.
This is not really correct--it's implementation-specific exactly what sort of performance result this will engender. Any modern compiler --either Intel, Microsoft, or GCC--should optimize it such that the increment instruction is performed after the evaluation of the expression. If there is no expression, then there will only be an increment operation.
Where it
does matter is in evaluative expressions (especially those that involve functions)--and should probably be avoided in such statements anyway due to problems with legibility and determinism (especially re: multithreaded applications).