ETI in VC71?

  • Thread starter Thread starter Arkadiy
  • Start date Start date
A

Arkadiy

Hi all,

I was under impression that the ETI bug was completely fixed in VC71.
However, recently I ran into a problem that makes me think otherwise.
The following minimal example demonstrates the problem that looks very
similar to ETI:

------------------------------
template<int n> struct Y
{
typedef void type;
};

template<> struct Y<4>
{};

template<class T>
T foo();

template <class T>
struct X
{
typedef typename Y<sizeof(foo<T>())>::type type;
};

int main()
{
return 0;
}
---------------------------------

Can anybody comment on this?

Thanks in advance and best regards,
Arkadiy
 
Arkadiy said:
Hi all,

I was under impression that the ETI bug was completely fixed in VC71.
However, recently I ran into a problem that makes me think otherwise.
The following minimal example demonstrates the problem that looks very
similar to ETI:

------------------------------
template<int n> struct Y
{
typedef void type;
};

template<> struct Y<4>
{};

template<class T>
T foo();

template <class T>
struct X
{
typedef typename Y<sizeof(foo<T>())>::type type;
};

int main()
{
return 0;
}
Click to expand...

AFIAK there were no significant changes in the way VC handles template
instantiation in VC7.1 (or VC8).

-cd
 
Arkadiy said:
I was under impression that the ETI bug was completely fixed in VC71.
However, recently I ran into a problem that makes me think otherwise.
The following minimal example demonstrates the problem that looks very
similar to ETI:
Click to expand...
I think this a bit different from the nightmare in previous VC versions.

[..]
Specifically, I think VC doesn't realize that
template <class T>
struct X
{
typedef typename Y<sizeof(foo<T>())>::type type;
Click to expand...

is a dependent name. I can't access my VC 7.1 installation right
now, but you could try to drop the typename and IIRC the
compiler won't complain. Or try to add a "+ 0 * sizeof(T)"
to make sure the compiler thinks it's a dependent name.

So the compiler see typedef Y<4>::type type;
in which case it's okay to instantiate Y<4>::type even if
X<T>::type is not instantiated.

So I think it's not exactly ETI. Nonetheless it's annoying
enough.

-hg
 
Holger said:
Arkadiy said:
I was under impression that the ETI bug was completely fixed in VC71.
However, recently I ran into a problem that makes me think otherwise.
The following minimal example demonstrates the problem that looks very
similar to ETI:
Click to expand...
I think this a bit different from the nightmare in previous VC versions.

[..]
Specifically, I think VC doesn't realize that
template <class T>
struct X
{
typedef typename Y<sizeof(foo<T>())>::type type;
Click to expand...

is a dependent name. I can't access my VC 7.1 installation right
now, but you could try to drop the typename and IIRC the
compiler won't complain. Or try to add a "+ 0 * sizeof(T)"
to make sure the compiler thinks it's a dependent name.
Click to expand...

Second one helps. Now I have to figure out whether it solves my
original problem or my minimal example was wrong.
So the compiler see typedef Y<4>::type type;
in which case it's okay to instantiate Y<4>::type even if
X<T>::type is not instantiated.

So I think it's not exactly ETI. Nonetheless it's annoying
enough.
Click to expand...

Thanks a lot.
Arkadiy
 
Holger said:
Arkadiy said:
I was under impression that the ETI bug was completely fixed in VC71.
However, recently I ran into a problem that makes me think otherwise.
The following minimal example demonstrates the problem that looks very
similar to ETI:
Click to expand...
I think this a bit different from the nightmare in previous VC versions.

[..]
Specifically, I think VC doesn't realize that
template <class T>
struct X
{
typedef typename Y<sizeof(foo<T>())>::type type;
Click to expand...

is a dependent name. I can't access my VC 7.1 installation right
now, but you could try to drop the typename and IIRC the
compiler won't complain. Or try to add a "+ 0 * sizeof(T)"
to make sure the compiler thinks it's a dependent name.
Click to expand...

Second one helps. Now I have to figure out whether it solves my
original problem or my minimal example was wrong.
So the compiler see typedef Y<4>::type type;
in which case it's okay to instantiate Y<4>::type even if
X<T>::type is not instantiated.

So I think it's not exactly ETI. Nonetheless it's annoying
enough.
Click to expand...

Thanks a lot.
Arkadiy
 
Holger said:
is a dependent name. I can't access my VC 7.1 installation right
now, but you could try to drop the typename and IIRC the
compiler won't complain. Or try to add a "+ 0 * sizeof(T)"
to make sure the compiler thinks it's a dependent name.

So the compiler see typedef Y<4>::type type;
in which case it's okay to instantiate Y<4>::type even if
X<T>::type is not instantiated.
Click to expand...

As I mentioned before, adding "+ 0 * sizeof(T)" makes the code compile.
However, if you take my original code and just replace 4 with any
other number, it also compiles. If this was a problem of the compiler
not recognizing a dependent name, the exact number used in the
specialization wouldn't matter, would it? But, since 4 is exactly
sizeof(int), this makes me to believe that the compiler tries to
temporaruly replace "T" with integer, as in ETI.

Regards,
Arkadiy
 
Arkadiy said:
As I mentioned before, adding "+ 0 * sizeof(T)" makes the code compile.
However, if you take my original code and just replace 4 with any
other number, it also compiles. If this was a problem of the compiler
not recognizing a dependent name, the exact number used in the
specialization wouldn't matter, would it? But, since 4 is exactly
sizeof(int), this makes me to believe that the compiler tries to
temporaruly replace "T" with integer, as in ETI.
Click to expand...
That depends on how you put it ;-) If you consider
Y<sizeof(foo<T>())>::type a non-dependent name it should
be interpreted. But, oc, T is not known at this point in time
and probably substituted by an int.

It's IMHO a bit different from the VC 6 ETI issues where
it seemed that the compiler instantiated templates during
parsing. Oc, both things might be symptoms of the same
issue.

BTW: The code compiles fine with VC 8 beta.

-hg
 
Back
Top