Movatterモバイル変換

Proposed resolution (10/00):

1. In 13.8.3 [temp.dep] paragraph 3, replace

   In the definition of a class template or in the definition of a memberof such a template that appears outside of the template definition, ifa base class of this template depends on atemplate-parameter,the base class scope is not examined during name lookup until theclass template is instantiated.

   with

   In the definition of a class template or a member of a class template,if a base class of the class template depends on atemplate-parameter, the base class scope is not examined duringunqualified name lookup either at the point of definition of the classtemplate or member or during an instantiation of the class template ormember.

2. Remove from 13.8.3 [temp.dep] paragraph 4:

   If a base class is a dependent type, a member of that class cannothide a name declared within a template, or a name from the template'senclosing scopes.

Paragraphs 3-4 of 13.8.3 [temp.dep] say, in part,

if a base class of [a class] template depends on atemplate-parameter, the base class scope is not examined duringname lookup until the class template is instantiated... If a baseclass is a dependent type, a member of that class cannot hide a namedeclared within a template, or a name from the template's enclosingscope.

John Spicer: The wording in paragraph 4 seems particularlyodd to me. It essentially changes the order in which scopes areconsidered. If a scope outside of the template declares a given name,that declaration hides entities of the same name from templatedependent base classes (but not from nondependent base classes).

In the following example, the calls off andgare handled differently becauseB::f cannot hide::f, butB::g doesn't try to hide anything, so itcan be called.

    extern "C" int printf(char *, ...);    template <class T> struct A : T {        void h(T t) {            f(t);  // calls ::f(B)            g(t);  // calls B::g        }    };    struct B {        void f(B){printf("%s", "in B::f\n");}        void g(B){printf("%s", "in B::g\n");}    };    void f(B){printf("%s", "in ::f\n");}    int main()    {        A<B> ab;        B b;        ab.h(b);    }

I don't think the current wording in the standard provides a usefulfacility. The author of classA can't be sure that a givencall is going to call a base class function unless the base class isexplicitly specified. Adding a new global function could cause theprogram to suddenly change meaning.

What Ithought the rule was is, "If a base class is adependent type a member of that class is not found by unqualifiedlookup".

Derek Inglis: My understanding is the same except that I'dremove the word "qualified" from your sentence.

Erwin Unruh: My interpretation is based on 13.8.4 [temp.dep.res] and especially 13.8.4.2 [temp.dep.candidate] (andlargely on my memory of the discussions). For all unqualified namesyou do something like the following algorithm:

1. check whether it is a dependent function call
2. Do a lookup in the definition context and remember what you found there
3. Do a Koenig-Lookup at instantiation time
4. perform overloading if necessary

Regarding names from base classes you cannot find them in 2) because youdon't know what base class you have. You cannot find them in 3) becausemembers of classes are not found by Koenig lookup (only namespaces areconsidered). So you don't find them at all (for unqualified names).

For a qualified name, you start lookup for each 'part' of the qualification.Once you reach a dependent part, you stop and continue lookup at theinstantiation point. For example:

    namespace A {      namepace B {template <class T> class C {  template <class U> class D {    typedef int E;    // ...  };};      };    };    template <class T> class F : public T {      typename A::B::C<int>::D<T>::E var1;      typename A::B::C<T>::D<int>::E var2;      typename F::T::X var3;    }

Forvar1 you do lookup forA::B::C<int>::Dat definition time, forvar2 you only do lookup forA::B::C. The rest of the lookup is done at instantiation timesince specialisations could change part of the lookup. Similarly thelookup forvar3 stops afterF::T at definitiontime.

My impression was that an unqualified name never refers to a namein a dependent base class.

(See alsoissue 197.)