scope question

Discussion in 'C++' started by Christof Warlich, Nov 28, 2007.

  1. Hi,

    just being curious:
    Anyone having a clue why the commented lines do not compile?

    Thanks,

    Christof

    class B {
    public:
    int x;
    };
    template<int t> class TB: public B {
    public:
    int y;
    TB() {
    // Does compile
    x = 0;
    B::x = 0;
    }
    };
    template<int t> class D: public TB<t> {
    public:
    D() {
    // Does not compile:
    //x = 0;
    //B::x = 0;
    //y = 0;
    // Does compile
    this->B::x = 0;
    this->x = 0;
    D<t>::x = 0;
    TB<t>::x = 0;
    this->y = 0;
    TB<t>::y = 0;
    }
    };
    int main() {}
     
    Christof Warlich, Nov 28, 2007
    #1
    1. Advertisements

  2. Christof Warlich

    Kira Yamato Guest

    Google "two phase name lookup C++"
     
    Kira Yamato, Nov 28, 2007
    #2
    1. Advertisements

  3. Christof Warlich

    Pavel Shved Guest

    Try changing line
    to
    this->B::x = "The conversion is impossible!";

    Still compiles. :) Try even more: change
    to
    this->std::iostream::x = "Still compiles...";

    And if you replace :public TB<t> with :public TB<2> it starts
    compiling commented strings...

    templates are soo tricky :) If you play with them a bit, you can
    deduce some rules, but for strict ones you should consult standard, i
    think.
    After some experiments i deduced that compiler delays checking of this-
    instantation of templated parents. So he merely doesnt see that B is
    our parent and x and y are member variables when compiling D's
    constructor.
     
    Pavel Shved, Nov 28, 2007
    #3
  4. oh, oh - I shouldn't have asked: For decades, I felt so
    comfortable with my naive belief in C++ ;-(.

    Anyway, thanks a lot for this insight, though I'd better
    try to forget .... ;-).
     
    Christof Warlich, Nov 28, 2007
    #4
  5. Christof Warlich

    Pavel Shved Guest

    Oh, no, you don't need to get disappointed with C++. The reason why
    is described in C++-faq-lite, which link to you may easilly find in
    google; check Templates section. I'd post it here, but i consider
    unfair repeating what i've learned from experience of this group
    subscribers.
     
    Pavel Shved, Nov 28, 2007
    #5
  6. Christof Warlich

    James Kanze Guest

    The difference is due to dependent vs. non-dependent name
    look-up. Basically, the compiler separates names in a template
    into two categories, dependent and non-dependent. If the name
    is non-dependent, it is lookup up at the point where the
    template is defined. If it is dependent, it is looked up when
    the template is instantiated, using ADN, and ony ADN.

    Basically, a name is dependent if it is used in a context which
    depends on the template arguments. The exact rules are a bit
    complicated, but that's the gist of it.
    Note that B is not dependent. Regardless of the instantiation
    argument, B is B, and cannot change. So the compiler will
    consider it during non-dependent name look-up.
    Obviously:). The compiler finds the x in B, in both cases.
    Here, on the other hand, the base class is dependent. The
    compiler cannot take it into account for non-dependent name
    lookup, since it has no idea what could be in it.
    That's because the names above are non-dependent, and are looked
    up immediately, here, at the point of definition. And because,
    at this time, the compiler cannot consider the base class,
    because it doesn't know what will or will not be in it. (There
    could be an explicit specialization that it hasn't seen yet, for
    example.)

    In the first and third cases, it's a simple case of the compiler
    not finding the name at all. In the second, the B:: tells the
    compiler to look in B, but the compiler doesn't have (or doesn't
    know that it has) a base of type B, so it doesn't have an object
    to associate with the x it finds in B.
    All of these introduce a dependent context, so name look-up is
    defered until instantiation.
    Try adding some instantiations:

    template<> class TB<0> {} ;

    int main()
    {
    TD< 0 > doh ;
    }

    That should cause a lot of errors. And also show why the
    compiler can't look at the base class in non-dependent name
    lookup.

    Functions are even more fun, since whether a function is
    dependent or not depends on its arguments. So we get things
    like:

    class A {} ;
    void f( int ) ;
    void f( A ) ;

    template< typename T >
    class TBase
    {
    public:
    void f( int ) ;
    void f( T ) ;
    } ;

    template< typename T >
    class TDerived : public TBase
    {
    public:
    void g()
    {
    this->f( 43 ) ; // calls TBase<>::f( int )
    // (if there is one)
    f( 43 ) ; // calls ::f(int)
    this->f( A() ) ; // calls TBase<>::f( A )
    // (if there is one)
    f( A() ) ; // calls ::f(A), even if
    // instantiated for A.
    f( T() ) ; // calls TBase<>::f( T ), even
    // if instantiated for A.
    }
    } ;

    Note that if you instantiate TDerived<A>, then the last two
    function calls in TDerived<>::g() are exactly the same, same
    name, same arguments. Except that one calls the global function
    (because it doesn't depend on T), and the other calls the
    function in the base class (because it does depend on T, so it's
    name lookup includes the base class).

    Now throw in a few overloads and conversions, and let operator
    overload resolution work with different sets of functions, and
    create some real confusion. (If any of a function's arguments
    are dependent, the function name is looked up in a dependent
    fashion.)
     
    James Kanze, Nov 28, 2007
    #6
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.