Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!umd5!uflorida!novavax!proxftl!bill From: bill@proxftl.UUCP (T. William Wells) Newsgroups: comp.misc Subject: Re: Basics of Program Design Summary: tail recursion? Message-ID: <395@proxftl.UUCP> Date: 30 Jun 88 18:35:24 GMT References: <901@td2cad.intel.com> <3061@rpp386.UUCP>Distribution: na Organization: Proximity Technology, Ft. Lauderdale Lines: 33 In article , webber@aramis.rutgers.edu (Bob Webber) writes: > In article <3061@rpp386.UUCP>, jfh@rpp386.UUCP (John F. Haugh II) writes: > > strlen (s) > > char *s; > > { > > if (*s) > > return (strlen (s + 1) + 1); > > else > > return (0); > > } > > > > not such a smart move. always consider the cost of your algorithm. > > A perfectly fine algorithm. Any decent compiler would remove the tail > recursion. Ahhhh. Last I heard, tail recursion implies a function call immediately before a return. This function has an add (or increment) before the return. Has the definition of tail recursion changed? Also, get REAL. Merely asserting that "any decent compiler would..." is not relevant. This just asserts that YOU think that a compiler that does not deal with tail recursion is not decent. In the real world, most compilers do NOT deal with tail recursion, it not often being very useful to do this for C programs. A perfectly good algorithm can be a BAD choice in the real world. Yes, the algorithm is "good", which is to say, it works and is of the best possible order, but it is poorer than the standard implementation since its constant factor is going to be larger. What you learn in school are the tools of the trade, what that unfortunate is running into is that school does not teach how to select the right tool for the job.