Hi all!

I've found a peculiar bug in Visual Studio 2010. I'm not really sure why it happens, or what I'm doing wrong.
Anyway, here's the code:


// compilerCrash.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <iostream>
template <class T>
class fatalError {
public:
T* fatalError::getObject(int i){
return new T(i);
}
T *fatalError::getObject(const char *j){
return new T(j);
}
};
class foo{
public:
foo(int i){
std::cout<<i;
}
foo(const char *j){
std::cout<<j;
}
void print(){
std::cout<<"printing";
}
};
int _tmain(int argc, _TCHAR* argv[])
{

foo f(20);
int id = (int)&f;
fatalError<foo> fatal;
fatal.getObject(id)->print();;
return 0;
}


Compiler Output:

1>------ Build started: Project: compilerCrash, Configuration: Debug Win32 ------
1>Build started 5/1/2012 8:37:12 AM.
1>InitializeBuildStatus:
1> Creating "Debug\compilerCrash.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>ClCompile:
1> compilerCrash.cpp
1>d:\siddu\programmming\tests\compilercrash\compilercrash\compilercrash.cpp(14): fatal error C1001: An internal error has occurred in the compiler.
1> (compiler file 'msc1.cpp', line 1420)
1> To work around this problem, try simplifying or changing the program near the locations listed above.
1> Please choose the Technical Support command on the Visual C++
1> Help menu, or open the Technical Support help file for more information
1> d:\siddu\programmming\tests\compilercrash\compilercrash\compilercrash.cpp(18) : see reference to class template instantiation 'fatalError<T>' being compiled
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:01.77
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========


On removing the fatalError:: part within the member function definitions, the compiler becomes normal. for some reason, it causes the compiler to crash.

Are you guys able to reproduce this? and why is this happening? I'm sure I'm missing something, but I'm not sure *what* I'm missing.

Thanks all!

This happens occasionally with compilers, they sometimes die on peculiar instruction arrangements. Usually shuffling things around or doing them a bit differently solves the issue, but it's good practice to make the developers working on the compiler aware of it (even if it's been reported before), so you should still file a bug report.

thanks for the info