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

Cornelius Riemenschneider c.r1 at gmx.de
Fri Feb 12 04:29:08 PST 2010


See http://llvm.org/bugs/show_bug.cgi?id=6179 where the same issue is tracked, with another gmpxx-distilled testcase and a similiar quote from the C++0x working draft.
Cornelius
-------- Original-Nachricht --------
> Datum: Fri, 12 Feb 2010 11:09:50 +0100
> Von: Enea Zaffanella <zaffanella at cs.unipr.it>
> An: John McCall <rjmccall at apple.com>
> CC: "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>
> Betreff: Re: [cfe-dev] Is clang name lookup too restrictive for dependent base classes?

> John McCall wrote:
> > On Feb 11, 2010, at 3:03 AM, Enea Zaffanella wrote:
> 
> [...]
> 
> >> 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.
> > 
> > Without the template<>, the compiler doesn't realize you're declaring
> > an explicit specialization.  But the design of template parameters in
> the
> > language (and Doug can speak more to this) is that parameter clauses
> > are matched up with argument clauses in the declared name — that is,
> > you match angle brackets to angle brackets.  Using a typedef screws
> > up this matching because it means that parts of the name without
> > angle-brackets are supposed to matched against.
> > 
> > That's why the language requires it.  From a user-design point of view,
> > gcc's permissiveness on this goes a long way towards explaining why
> > nobody but language geeks understands how this matching is
> > supposed to work.
> > 
> > John.
> 
> Unfortunately, I made an error when extracting the testcase from GMP.
> 
> The complete testcase showing the problem (that could be found in 
> gmpxx.h, both versions 4.3.2 and 5.0.1) is as follows:
> ======================================================
> // Declaration of class template (__gmp_expr).
> template <typename T>
> struct S;
> 
> // Definition of explicit specialization (__gmp_expr<mpz_t, mpz_t>).
> template <>
> struct S<int> {
>    S foo(S);
> };
> 
> // Typedef declaration for explicit specialization (mpz_class).
> typedef S<int> SInt;
> 
> // Out-of-line definition of member of explicit specialization
> // (e.g., mpz_class::operator+=).
> SInt SInt::foo(SInt x)
> {
>    return x;
> }
> ======================================================
> 
> The big difference wrt previous testcase is that the class template 
> specialization is *defined* before introducing its typedef alias.
> 
> Here, clang complains the same way as above:
> ======================================================
> # clang++ -fsyntax-only test.cc
> test.cc:15:1: error: cannot use typedef 'SInt' (aka 'S<int>') in scope 
> specifier
>        for out-of-line declaration
> SInt SInt::foo(SInt x)
> ^
> 1 diagnostic generated.
> ======================================================
> 
> This code is accepted by g++ and Comeau and, as far as I can tell, it is 
> standard compliant. In fact, since we now have the explicit 
> specialization, C++98 14.7.3 p5 becomes relevant.
> Quoting the end of that paragraph:
> 
>    "Definitions of members of an explicitly specialized class
>     are defined in the same manner as members of normal classes,
>     and not using the explicit specialization syntax."
> 
> Since these definitions do not use the "template <>" prefixes, there is 
> no way (or need) to perform the matching you were mentioning above, 
> hence there is no need to forbid the use of typedef names.
> 
> 
> Regards,
> Enea Zaffanella.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01



More information about the cfe-dev mailing list