[cfe-dev] Is clang name lookup too restrictive for dependent base classes?

Enea Zaffanella zaffanella at cs.unipr.it
Thu Feb 11 03:03:14 PST 2010


Douglas Gregor wrote:
> On Feb 10, 2010, at 2:51 PM, Enea Zaffanella wrote:
> 
>> Hello.
>>
>> The following example is a simplified version of code occurring in 
>> doxygen-1.6.2 (in the qtools module):

[...]

> g++ is too permissive. This is two-phase name lookup, which Clang is very strict about.
> 
> 	- Doug
> 

I see. I just tried it on Comeau:
it gives an error if "Compile in strict C++03 mode" is selected,
whereas it accepts it if "Compile in relaxed mode" is selected.

Is there any plan to increase compatibility with g++ by adding some sort 
of "relaxed mode" option?


I have another example (extracted from some version of gmpxx.h):
===============================
template <typename T>
struct C {
   void foo();
};

typedef C<int> CInt;

template <>
void CInt::foo() {}
===============================

Clang complains as follows:

===============================
# clang++ -fsyntax-only test.cc
test.cc:9:1: error: cannot use typedef 'CInt' (aka 'C<int>') in
       scope specifier for out-of-line declaration
void CInt::foo() {}
^
1 diagnostic generated.
===============================


In contrast, both g++ (4.3.0) and Comeau (no matter if in strict or 
relaxed mode) accept it.

I checked clang source for a reference to the standard and I found the 
following (Sema/SemaTemplate.cpp):

     // C++0x [temp.expl.spec]p17:
     //   A member or a member template may be nested within many
     //   enclosing class templates. In an explicit specialization for
     //   such a member, the member declaration shall be preceded by a
     //   template<> for each enclosing class template that is
     //   explicitly specialized.
     // We interpret this as forbidding typedefs of template
     // specializations in the scope specifiers of out-of-line decls.

Both g++ and Comeau will refuse the example above if the "template <>" 
was omitted ... but I don't see a strong relation between this behavior 
and the presence of a typedef name.

Can you explain the point of view underlying clang implementation?

Regards,
Enea.



More information about the cfe-dev mailing list