On 11/28/05, Glen Turner <[EMAIL PROTECTED]> wrote:
> This is called a "pinball API" since the result to someone
> who doesn't recognise that the return value needs to be
> tested is essentially random. Much better to make that
> requirement explicit in the API.
>
> bool factorial(unsigned int *n);
Oh, I was trying to make a function with the same inputs and outputs
(the same black box) as the original function. Otherwise, I'd have
definitely made the input unsigned, for exactly this reason. I think
it's a good thing to make the requirement as explicit as possible.
However, I'm not such a big fan of mixing my input and output in the
same variable, so I probably would not have taken that approach.
> The predominance of pinball APIs in the C standard lead to
> a lot of criticism of the standard C library, as the poor
> design of the API is a major source of buffer overflows in
> code.
Yeah, but unfortunately, this is also the strongest argument in favor
of using pinball APIs -- consistency with the standard C library.
(This is, of course, the problem that the C++ folks were trying to
solve with exceptions. It was a perfectly reasonable idea, but in
practice, they don't tend to be used all the time, due to performance
issues, programmer confusion, and other issues.)
> Also note that you don't need to abandon recursion because of
> the stack issue -- you simply need to ensure the stack is not
> exhausted.
I have been known to do embedded systems and game console dev, at
times. In those environments, I almost always try to keep my stack
size as lean as possible.
> Simplest way to do that is to do some modelling
> and restrict the range of the input:
>
> int recursion(int r) {
> assert(r < 100);
> ...
> recursion(simpler(r));
> }
On systems with 32 bit integers, for factorial, you have to restrict r
to be less than or equal to 12. (Which means the stack is never going
to get that deep, anyway, really. It's probably not the best example
for demonstrating the value of iterative conversion. I've had cases
that cropped up in practice where it was much more valuable.)
Tess
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
