From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Description of problem: Compiler is failing to compile the following code: test.cpp: typedef int PAMSInt; typedef unsigned short* PAMSStr; unsigned short PS_T[] = { 0x0062, 0x0061, 0x006e, 0x0064, 0x0073, 0 } ; template <class A, class B> class PAMSClass { public: PAMSClass(A a, B b) { a1 = a; b1 = b; } private: A a1; B b1; }; /* This line will cause the compiler to fail with an error stating: * test.cpp:24: parse error before `1' */ PAMSClass<PAMSStr, PAMSInt> pamsclass(PAMSStr(PS_T),PAMSInt(1)); /* This line will compile normally. The difference between this and * the previous line is that a cast is used instead of constructing * a temporary of PAMSStr. */ //PAMSClass<PAMSStr, PAMSInt> pamsclass((PAMSStr)PS_T,PAMSInt(1)); /* This line will compile normally. The difference between this and * the first line above is that we cast the 'unsigned short' array * to a 'unsigned short*' pointer when constructing the temporary. */ //PAMSClass<PAMSStr, PAMSInt> pamsclass(PAMSStr((unsigned short*)PS_T),PAMSInt(1)); int main() { return 0; } Version-Release number of selected component (if applicable): gcc-2.96-118.7.2 How reproducible: Always Steps to Reproduce: 1. Place text of code in description in a file named test.cpp 2. Run g++ test.cpp -o test 3. Note compile failure (test.cpp:23: parse error before `1') Actual Results: The compiler produced the following error and failed to produce the intended executable: test.cpp:23: parse error before `1' Expected Results: No errors should have been produced and an executable should have been created. Additional info: The included file contains workarounds to the problem which help to narrow down the area of the bug. Please try both workarounds to ensure they compile correctly. The bug looks to be contained to the construction of temporary objects when being used as arguments to a template class constructor when an arguement to the temporary constructor is an array where a pointer is expected.
This seems to be fixed in gcc 3.4's new C++ parser (fails in gcc-2.96-rh, gcc-3.0.x .. gcc-3.3.x).
Indeed, fixed in gcc 3.4.
Oops, didn't mean to close 2.1AS bug.
I don't think it is going to be fixed in older compilers though.