Well, I would advice only to use it if you *know* the maximum nesting depth. Otherwise it can crash easily.
I was not focusing on the problems that could arise using recursion, my point simply was that in this case, use of recursion was a no-need.
Of course when using recursion you _MUST_ keep an eye on the stack, but then, a good parameter design for the recursive function could help a lot. Pointers are a must; while structures/records should be avoided in primis, as they are stack-hungry ;-)
A good example of stack overflow crashes is a (Pascal) software happened in a huge railway signal box in germany (near Hamburg) in 1995 (http://catless.ncl.ac.uk/Risks/17.02.html#subj3). The software worked ok on testing but on go live it crashed with stack overflow because suddenly the data amount (and therefore the nesting depth) was significantly larger than in the tests. It is much harder to judge the stack memory use than the heap use and often the stack is more limited than the heap so you run into such issues easier.
I don't know anything in detail about this crash (shit happens, I might say) all I can say out of my knowledge is that maybe in that specific situation some possible scenarios have been underestimated. I would ask myself why should you need recursion in that case too... but the approaches are different, and subjective, too. I would have gone through a tree-node solution instead; but that's me, I know. As I say, recursion is primarily for cases where/when you don't/can't have any finite states to start with. A railway net, by definition, although the possibilities of the shifts may result in a big number of trees, _is_ finite. IMHO. Hence, the use of recursion, again, is just a nice thing for your software to have, not necessarily the most adequate implementation of the human algorithm otherwise behind it.
I found, one day, that the easiest thing to do when you have no idea about how to have a computer replacing a human, is just to have as close as possible a representation of the human work-flow; then have a computer just being able to perform and cross-check it just faster. BTW, we all know that humans don't have a stack big enough to deal with recursion at reasonable speeds... ;-)
Cheers, A. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
