🚀 go-pugleaf

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?

	template <unsigned n> class Factorial
	{
	public:
		unsigned eval() { return n*Factorial<n-1>.eval(); }
	};

	class Factorial<0>
	{
	public:
		unsigned eval() { return 1; }
	};

	#include <iostream.h>

	int main()
	{
	Factorial<6> f6;
	cout << f6.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.
	-- Pete

In <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?

>	template <unsigned n> class Factorial
>	{
>	public:
>		unsigned eval() { return n*Factorial<n-1>.eval(); }
>	};

>	class Factorial<0>
>	{
>	public:
>		unsigned eval() { return 1; }
>	};

>	#include <iostream.h>

>	int main()
>	{
>	Factorial<6> f6;
>	cout << f6.eval() << endl;
>	return 0;
>	}

*****>	Has anyone got a *real* justification for this?  This is a very
	obfuscated way of writing factorial.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu

Jamshid Afshar jamshid@emx.utexas.edu writes:

 > This would require
 > that compilers not expand a template function or member function
 > unless it is actually called.

This was discussed briefly in the ANSI/ISO committee and there seemed to
be consensus that a template member function should not be generated unless
it was used. This is therefore the most likely outcome as a more precise
specification is worked out, but it is not the only opinion that has ever
been voiced on this matter.

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_

In article <Bxu3J4.F93@news.cso.uiuc.edu> pl2440@meibm31.cen.uiuc.edu (Paul Jay Lucas) writes:
>
>*****>	Has anyone got a *real* justification for this?  This is a very
>	obfuscated way of writing factorial.

	Has anyone got a *real* justification for recursive functions?  They
just provide a very obfuscated way of writing factorial().
	The point of my original posting was simply that there is no work to
be done to specify how such things work, because they already work in exactly
the way you'd expect.  Whether there are useful things that can be done with
such constructs is left as an exercise for the reader...
	-- Pete

In <1992Nov17.172152.14255@borland.com> pete@borland.com (Pete Becker) writes:

>In article <Bxu3J4.F93@news.cso.uiuc.edu> pl2440@meibm31.cen.uiuc.edu (Paul Jay Lucas) writes:
>>
>>*****>	Has anyone got a *real* justification for this?  This is a very
>>	obfuscated way of writing factorial.

>	Has anyone got a *real* justification for recursive functions?  They
>just provide a very obfuscated way of writing factorial().

*****>	Some algorithms are naturally recursive; most (other) people
	would agree that factorial is naturally expressed recursively.

>	The point of my original posting was simply that there is no work to
>be done to specify how such things work, because they already work in exactly
>the way you'd expect.

*****>	Huh?  I don't understand that paragraph.

>Whether there are useful things that can be done with
>such constructs is left as an exercise for the reader...

*****>	No, the point is whether it should be mandated that recursive
	templates be part of the standard or not.  If they're trivial to
	implement in compilers, then go ahead; if not, then I think
	justification is in order.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu