Compatibility with VS2008 vs. C++ Standard

[hylton__ron]

I have code which compiles and functions correctly using icl 10.1.021 and VS .Net 2003 but does not compile with icl 10.1.021 and VS 2008. The problem boils down to this:

I have a template library with, say,
template [class X] class A {...}. (Sorry about the square brackets for the template parameter but angle brackets were doing odd things to the post.)

The application code also has things like
class X {...}
or perhaps
template class X {...}.

When using VS .Net 2003 all uses of X within template A correctly resolve to the template parameter X. But when using VS 2008 (and the exact same icl version) some uses of X within template A incorrectly resolve to the X in the enclosing scope. (Perhaps all of them do, but the exact rules aren't clear to me.)

I submitted an issue on this but it is not going to be fixed; compatibility with VS 2008 (from which the bug has been copied) is more important than compliance with the C++ Standard.

I'm now at a loss as to how to write template libraries. If the application code using the library happens to include a name that clashes with one of the template parameters in the library the meaning of the template will change. Probably the code won't compile, but I'm quite worried that the code will compile but function incorrectly.

There is also the issue of getting code to "work" around this on Windows and then porting to a platform with a Standard-compliant compiler (e.g. gcc, which handles this correctly).

Does anyone have any ideas on how to approach this? I can't switch to gcc on Windows because in the past I've encountered severe performance issues relating to the way gcc handles exceptions on Windows. And I don't think I can stick with .NET 2003 much longer as support for it is being phased out in other packages I use.

Thanks,
Ron

[Dale_S_Intel]

Hello Ron,
Thanks for submitting the issue to Premier Support, I'm sorry we weren't able to address it to your satisfaction. It might help to clarify one or two things though. The reduced case our compiler engineer created is like below:

template
struct WrapNoInit : public Domain // direct base class
{
WrapNoInit() : Domain() {} // use
};
template class Domain {};
class Interval : public Domain {}; // indirect base class

WrapNoInit w;

The problem is caused by the fact that the use of the name Domain -- which in context is required to be a reference to a base class or nonstatic data member -- is potentially ambiguous. The name might be taken to refer to the direct base class (which is named "Interval" outside the template) or to the indirect base class actually named "Domain" (which is an indirect base class because it is a base class of Interval).

We should clarify that the problem affects only cases where a template parameter name which is used to identify a base class of a template class matches the name of an actual base class of the class used as an argument to that template. Thus the problem is rather narrower than it might seem at first blush. In particular, it is not the case that a name collision with any symbol will cause a problem, only between the template parameter and a base class.

The work around is to eliminate the ambiguity by renaming the template parameter, e.g.:
template
struct WrapNoInit : public DomainA // direct base class
{
WrapNoInit() : DomainA() {} // use
};

template class Domain {};

class Interval : public Domain {}; // indirect base class

WrapNoInit w;

I realize that this should not be needed according to the standard, but the requirements of running in an MS environment mean we sometimes need to favor the defacto MS "standard". In particular, we need to be able to compile MS headers as we require them, so it's not easy for us to ignore MS compatibility. I would recommend that you report this issue to Microsoft as well.

Thanks!

Dale