It was just brought to my attention that this fails to compile:
template <typename> void c();
#include <stack>
In file included from
/sbcimp/run/pd/gcc/32-bit/4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../include/c++/4.3.2/stack:67,
from mark.cc:2:
/sbcimp/run/pd/gcc/32-bit/4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../include/c++/4.3.2/bits/stl_stack.h:
In function bool std::operator<(const std::stack<_Tp, _Seq>&, const
std::stack<_Tp, _Seq>&):
/sbcimp/run/pd/gcc/32-bit/4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../include/c++/4.3.2/bits/stl_stack.h:257:
error: `.' cannot appear in a constant-expression
/sbcimp/run/pd/gcc/32-bit/4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../include/c++/4.3.2/bits/stl_stack.h:257:
error: parse error in template argument list
The problem is here:
template<typename _Tp, typename _Seq>
inline bool
operator<(const stack<_Tp, _Seq>& __x, const stack<_Tp, _Seq>& __y)
{ return __x.c < __y.c; }
The presence of the template ::c means that "c <" is parsed as the start of a
template-id, which then fails.
I *think* the compiler is doing the right thing here, but that doesn't help
users who've declared a template 'c'. libstdc++ could make it a non-issue by
using parentheses to prevent __x.c being parsed as a template-id:
{ return (__x.c) < __y.c; }
I've only tested it with 4.3.2 but it apparently fails with 3.2 - 4.3.3, and I
assume with 4.4 too.
--
Summary: Parse error in <stack> when user declares template-name
c
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
