🚀 go-pugleaf

In article <1992Nov16.220526.21566@borland.com> pete@borland.com (Pete Becker) writes:
>In article <83733@ut-emx.uucp> jamshid@emx.cc.utexas.edu (Jamshid Afshar) writes:
>>Has ANSI decided anything about the expansion of a recursive template
>>definition?
>
Interesting...I tried running the following example with gcc 2.3.1...
>	template <unsigned n> class Factorial
>	{
>	public:
>		unsigned eval() { return n*Factorial<n-1>.eval(); }
                                           ^^^^^^^^^^^^^^^^^^^^^
                                           what?? there's no instance here!
I used:
                static unsigned eval() { return n*(Factorial<n-1>::eval()); }
>	};
>
>	class Factorial<0>
>	{
>	public:
>		unsigned eval() { return 1; }
again, I used
                static unsigned eval() { return 1; } 
>	};
>
>	#include <iostream.h>
>
>	int main()
>	{
>	Factorial<6> f6;
>	cout << f6.eval() << endl;
I used
        cout << (Factorial<6>::eval()) << endl;
>	return 0;
>	}
>
>	That's from memory, so I may have some of the details wrong, but it
>worked in BC 3.0, and from discussions I've had the same sort of thing works
>with cfront.
Well, it seems that it would make more sense to have no instantations of the
class at all...
>	-- Pete
Interesting that it actually works with gcc 2.3.1...impressive...

Come to think of it, there shouldn't be any reason why recursive templates 
shouldn't work...anybody have an argument against it?  (besides it being a
vehicle for more obsfucated code :-))

Curiously, gcc 2.3.1 gives me a warning about shadowing member 'eval' with
member function... I guess I should use virtuals, eh?

Well, more thoughts on this later...




--
-----
Sean Chen.  hhc@athena.mit.edu
"Nunc in scutella iaceo,/et volitare nequeo,/dentes fredentes video./Miser!"
  Olim lacus colueram, _Carmina Burana_