Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluatesto zero at compile time

[Nickolai Dobrynin <dobrynin at miller dot cs dot uwm dot edu>]

Hello!

Actually, the original example from the "Generative Programming" book
looked like this:

#include <iostream>
using namespace std;

template<int n>
struct Fib
{ enum { RET = Fib<n-1>::RET + Fib<n-2>::RET };
};

template<>
struct Fib<0>
{ enum { RET = 0 };
};

template<>
struct Fib<1>
{ enum { RET = 1 };
};

void main()
{ cout << Fib<8>::RET << endl;
}

-- which, evidently, is not identical to what I was submitting in my
original message. After eliminating the "enum hack" (an optional step),
i.e. replacing enum with const static int,

#include <iostream>
using namespace std;

template<int n>
struct Fib { const static int RET = Fib<n-1>::RET + Fib<n-2>::RET; };

struct Fib<0> { const static int RET = 0; };
struct Fib<1> { const static int RET = 1; };

int main()
{
  cout << Fib<40>::RET << endl;


  return 0;
}

this will indeed produce a valid output.

I just think of it as being totally counter intuitive that the same nifty
feature is not valid (is NO LONGER valid, would be a better way to say it)
on non-constant initializers.

So, would indeed this be possible to restore the behavior of 2.95.x or it
would come in conflict with something else? Any opinions on that?


Regards,

Nickolai


PS  Is it a normal behavior that the option -ftemplate-depth-... is no
longer needed in order for the example above to compile properly?


On Tue, 2 Jul 2002, Paolo Carlini wrote:

> Hi,
>
> from a very practical point of view, would be difficult to restore the
> behaviour of 2.95.x? Note that Intel and Comeau adopts that "particular"
> initialization order and the current "equivalent" one ;-) breaks a whole
> body of literature on template metaprogramming...
>
> Ciao, Paolo.
>
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7181
>
>
>