accessing members of a templated base class

Discussion in 'C++' started by John Harrison, Aug 10, 2003.

  1. This code fails to compile on Comeau C++ and VC++ 7.1 (with language
    extensions disabled)

    template <class T>
    struct B
    {
    T b;
    };

    template <class T>
    struct D : B<T>
    {
    void f() { b = 1; }
    };

    int main()
    {
    D<int> x;
    x.f();
    }

    Error messages refer to 'b = 1;' with the message 'undefined identifier b'.
    Substituting this->b for b or making B a non-template class both make the
    code compile.

    What's going on here? I was so surprised when I saw this on VC++ that I
    assumed it was a compiler bug, but apparently not.

    john
     
    John Harrison, Aug 10, 2003
    #1
    1. Advertising

  2. "John Harrison" <> wrote...
    > This code fails to compile on Comeau C++ and VC++ 7.1 (with language
    > extensions disabled)
    >
    > template <class T>
    > struct B
    > {
    > T b;
    > };
    >
    > template <class T>
    > struct D : B<T>
    > {
    > void f() { b = 1; }
    > };
    >
    > int main()
    > {
    > D<int> x;
    > x.f();
    > }
    >
    > Error messages refer to 'b = 1;' with the message 'undefined identifier

    b'.
    > Substituting this->b for b or making B a non-template class both make the
    > code compile.
    >
    > What's going on here? I was so surprised when I saw this on VC++ that I
    > assumed it was a compiler bug, but apparently not.


    Why do you say "apparently not"? I cannot find anything in the Standard
    that would make the look-up of name 'b' in D<T>::f() fail. As far as the
    Standard goes, the usual rules of 10.2 should apply. The base class has
    to be searched if 'b' is not found in D definition.

    14.6/8 says "When looking for the declaration of a name used in a template
    definition, the usual lookup rules (3.4.1, 3.4.2) are used for nondependent
    names."

    3.4.1/8 says "A name used in the definition of a function that is a member
    function (9.3)29) of class X shall be declared in one of the following
    ways:
    - before its use in the block in which it is used or in an enclosing block
    (6.3), or
    - shall be a member of class X or be a member of a base class of X (10.2),
    or ..."

    So, "shall be a member of class X or be a member of a base class of X"
    should do it. 'b' is a member of the base class.

    Well, at least that's how I read it. Perhaps Greg Comeau or other
    knowledgeable people will enlighten us both.

    Victor
     
    Victor Bazarov, Aug 10, 2003
    #2
    1. Advertising

  3. On Sun, 10 Aug 2003 14:13:59 +0100, "John Harrison" <> wrote:

    >This code fails to compile on Comeau C++ and VC++ 7.1 (with language
    >extensions disabled)
    >
    >template <class T>
    >struct B
    >{
    > T b;
    >};
    >
    >template <class T>
    >struct D : B<T>
    >{
    > void f() { b = 1; }
    >};
    >
    >int main()
    >{
    > D<int> x;
    > x.f();
    >}
    >
    >Error messages refer to 'b = 1;' with the message 'undefined identifier b'.
    >Substituting this->b for b or making B a non-template class both make the
    >code compile.


    Am I glad that I haven't even checked whether I _have_ VC 7.1... ;-)

    It compiles just fine with 7.0, with and without language extensions
    disabled (/Za).



    >What's going on here? I was so surprised when I saw this on VC++ that I
    >assumed it was a compiler bug, but apparently not.


    Apparently it is a compiler bug.

    At least, I agree with Victor that the usual look-up rules should apply.
     
    Alf P. Steinbach, Aug 10, 2003
    #3
  4. John Harrison

    Pete Becker Guest

    "Alf P. Steinbach" wrote:
    >
    > Am I glad that I haven't even checked whether I _have_ VC 7.1... ;-)


    Are you also glad that you haven't checked whether you have the EDG
    front end? <g> It rejects this code, too.

    >
    > It compiles just fine with 7.0, with and without language extensions
    > disabled (/Za).
    >
    > >What's going on here? I was so surprised when I saw this on VC++ that I
    > >assumed it was a compiler bug, but apparently not.

    >
    > Apparently it is a compiler bug.
    >
    > At least, I agree with Victor that the usual look-up rules should apply.


    Since EDG rejects it, I suspect that the analysis is wrong. I don't
    claim to understand two-phase lookup, but it looks to me like 'b' is a
    dependent name. After all, its meaning depends on the defintion of B<T>,
    and B<T> can be specialized for various T's. During phase one it has to
    be explicitly qualified, in order to tell the compiler that not having a
    'b' in B<T> is an error.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Aug 10, 2003
    #4
  5. On Sun, 10 Aug 2003 10:12:08 -0400, Pete Becker <> wrote:

    >"Alf P. Steinbach" wrote:
    >>
    >> Am I glad that I haven't even checked whether I _have_ VC 7.1... ;-)

    >
    >Are you also glad that you haven't checked whether you have the EDG
    >front end? <g> It rejects this code, too.


    I'm pretty sure that I don't have that, since I don't have Comeau,
    unless it's used by Visual C++ 7.1.



    >> It compiles just fine with 7.0, with and without language extensions
    >> disabled (/Za).
    >>
    >> >What's going on here? I was so surprised when I saw this on VC++ that I
    >> >assumed it was a compiler bug, but apparently not.

    >>
    >> Apparently it is a compiler bug.
    >>
    >> At least, I agree with Victor that the usual look-up rules should apply.

    >
    >Since EDG rejects it, I suspect that the analysis is wrong.


    EDG lists Comeau Computing as one of the compilers (or at least, companies)
    that use their front-end.

    If that's correct that means it's still just two compilers (or compiler
    parts) that reject the code: Visual C++ 7.1 and Comeau.

    If Visual C++ 7.1 also uses the EDG front-end then it's just one.
     
    Alf P. Steinbach, Aug 10, 2003
    #5
  6. > >
    > > What's going on here? I was so surprised when I saw this on VC++ that I
    > > assumed it was a compiler bug, but apparently not.

    >
    > Why do you say "apparently not"?


    Because two apparently unrelated compilers produce effectively identical
    error messages. I hadn't considered Alf's suggestion that VC++ 7.1 might use
    the EDG front end. However Microsoft aren't on EDG's list of corporate
    licensees and you might expect them to make a fuss about it if MS were using
    EDG.

    john
     
    John Harrison, Aug 10, 2003
    #6
  7. On Sun, 10 Aug 2003 15:47:03 +0100, "John Harrison" <> wrote:

    >> >
    >> > What's going on here? I was so surprised when I saw this on VC++ that I
    >> > assumed it was a compiler bug, but apparently not.

    >>
    >> Why do you say "apparently not"?

    >
    >Because two apparently unrelated compilers produce effectively identical
    >error messages. I hadn't considered Alf's suggestion that VC++ 7.1 might use
    >the EDG front end. However Microsoft aren't on EDG's list of corporate
    >licensees and you might expect them to make a fuss about it if MS were using
    >EDG.


    Only about 50% of the licensees are on the public list.
     
    Alf P. Steinbach, Aug 10, 2003
    #7
  8. John Harrison

    Pete Becker Guest

    "Alf P. Steinbach" wrote:
    >
    > On Sun, 10 Aug 2003 10:12:08 -0400, Pete Becker <> wrote:
    >
    > >"Alf P. Steinbach" wrote:
    > >>
    > >> Am I glad that I haven't even checked whether I _have_ VC 7.1... ;-)

    > >
    > >Are you also glad that you haven't checked whether you have the EDG
    > >front end? <g> It rejects this code, too.

    >
    > I'm pretty sure that I don't have that, since I don't have Comeau,
    > unless it's used by Visual C++ 7.1.
    >
    > >> It compiles just fine with 7.0, with and without language extensions
    > >> disabled (/Za).
    > >>
    > >> >What's going on here? I was so surprised when I saw this on VC++ that I
    > >> >assumed it was a compiler bug, but apparently not.
    > >>
    > >> Apparently it is a compiler bug.
    > >>
    > >> At least, I agree with Victor that the usual look-up rules should apply.

    > >
    > >Since EDG rejects it, I suspect that the analysis is wrong.

    >
    > EDG lists Comeau Computing as one of the compilers (or at least, companies)
    > that use their front-end.
    >
    > If that's correct that means it's still just two compilers (or compiler
    > parts) that reject the code: Visual C++ 7.1 and Comeau.
    >
    > If Visual C++ 7.1 also uses the EDG front-end then it's just one.


    Visual C++ 7.1 does not use the EDG front end. Even if it did, counting
    compilers doesn't tell you much. EDG is usually right.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Aug 10, 2003
    #8
  9. "Pete Becker" <> wrote in message
    news:...
    > "Alf P. Steinbach" wrote:
    > >
    > > Am I glad that I haven't even checked whether I _have_ VC 7.1... ;-)

    >
    > Are you also glad that you haven't checked whether you have the EDG
    > front end? <g> It rejects this code, too.
    >
    > >
    > > It compiles just fine with 7.0, with and without language extensions
    > > disabled (/Za).
    > >
    > > >What's going on here? I was so surprised when I saw this on VC++ that
    > > > I assumed it was a compiler bug, but apparently not.

    > >
    > > Apparently it is a compiler bug.
    > >
    > > At least, I agree with Victor that the usual look-up rules should
    > > apply.

    >
    > Since EDG rejects it, I suspect that the analysis is wrong. I don't
    > claim to understand two-phase lookup, but it looks to me like 'b' is a
    > dependent name.


    Exactly. Use

    template <class T>
    struct B
    {
    T b;
    };

    template <class T>
    struct D : B<T>
    {
    void f() { B<T>::b = 1; }
    };

    or perhaps

    template <class T>
    struct B
    {
    T b;
    };

    template <class T>
    struct D : B<T>
    {
    using B<T>::b;
    void f() { b = 1; }
    };

    if you'll be using B's b in many places in D (note, if B's b was protected,
    you should probably also make the using decl. protected).

    /kv
     
    Kristoffer Vinther, Aug 10, 2003
    #9
  10. On Sun, 10 Aug 2003 14:13:59 +0100, John Harrison wrote:

    > This code fails to compile on Comeau C++ and VC++ 7.1 (with language
    > extensions disabled)
    >
    > template <class T>
    > struct B
    > {
    > T b;
    > };
    >
    > template <class T>
    > struct D : B<T>
    > {
    > void f() { b = 1; }
    > };
    >
    > int main()
    > {
    > D<int> x;
    > x.f();
    > }
    >
    > Error messages refer to 'b = 1;' with the message 'undefined identifier b'.
    > Substituting this->b for b or making B a non-template class both make the
    > code compile.
    >
    > What's going on here? I was so surprised when I saw this on VC++ that I
    > assumed it was a compiler bug, but apparently not.
    >
    > john


    It's definitely not a compiler bug. HP's aCC compiler even tells you where
    to look in the Standard:

    Error (future) 641: "xx.cc", line 16 # Undeclared variable 'b'. A variable
    with the same name exists in a template base class, but is not visible
    according to the Standard lookup rules (See [temp.dep], 14.6.2(3) in the
    C++ Standard). You can make it visible by writing 'this->b'.
    void f() { b = 3; }
    ^

    There is an explanation of this rule in the book "C++ Templates - The
    Complete Guide" by Vandevoorde and Josuttis (section 9.4.2).
     
    Simon Saunders, Aug 10, 2003
    #10
  11. John Harrison

    Pete Becker Guest

    Pete Becker wrote:
    >
    > "Alf P. Steinbach" wrote:
    > >
    > > If Visual C++ 7.1 also uses the EDG front-end then it's just one.

    >
    > Visual C++ 7.1 does not use the EDG front end.


    What I should have said is, do you have any reason to think that VC++
    used EDG's front end? I have no information either way.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Aug 10, 2003
    #11
  12. On Sun, 10 Aug 2003 10:12:08 -0400, Pete Becker <> wrote:

    >"Alf P. Steinbach" wrote:
    >>
    >> Am I glad that I haven't even checked whether I _have_ VC 7.1... ;-)

    >
    >Are you also glad that you haven't checked whether you have the EDG
    >front end? <g> It rejects this code, too.
    >
    >>
    >> It compiles just fine with 7.0, with and without language extensions
    >> disabled (/Za).
    >>
    >> >What's going on here? I was so surprised when I saw this on VC++ that I
    >> >assumed it was a compiler bug, but apparently not.

    >>
    >> Apparently it is a compiler bug.
    >>
    >> At least, I agree with Victor that the usual look-up rules should apply.

    >
    >Since EDG rejects it, I suspect that the analysis is wrong. I don't
    >claim to understand two-phase lookup, but it looks to me like 'b' is a
    >dependent name. After all, its meaning depends on the defintion of B<T>,
    >and B<T> can be specialized for various T's. During phase one it has to
    >be explicitly qualified, in order to tell the compiler that not having a
    >'b' in B<T> is an error.


    ?

    I agree that this two-phase thing is a mess... ;-) But just reading the
    standard it says that such names are "unbound" (including the operator)
    and become bound at template instantiation time. So I fail to see why
    it even _could_ be correct to fail to compile this code; all the
    information the compiler needs is there, when it needs it.


    PS: I also don't understand "that not having a 'b' in B<T> is an error".
     
    Alf P. Steinbach, Aug 10, 2003
    #12
  13. John Harrison

    Pete Becker Guest

    "Alf P. Steinbach" wrote:
    >
    > PS: I also don't understand "that not having a 'b' in B<T> is an error".


    If D<T> mentions 'this->b' but doesn't define 'b' then 'b' must be
    defined in its base. If B<int> doesn't have a member named 'b' then the
    name is undefined.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Aug 10, 2003
    #13
  14. John Harrison

    Pete Becker Guest

    "Alf P. Steinbach" wrote:
    >
    > On Sun, 10 Aug 2003 10:12:08 -0400, Pete Becker <> wrote:
    >
    > >Since EDG rejects it, I suspect that the analysis is wrong. I don't
    > >claim to understand two-phase lookup, but it looks to me like 'b' is a
    > >dependent name. After all, its meaning depends on the defintion of B<T>,
    > >and B<T> can be specialized for various T's. During phase one it has to
    > >be explicitly qualified, in order to tell the compiler that not having a
    > >'b' in B<T> is an error.

    >
    > ?
    >
    > I agree that this two-phase thing is a mess... ;-) But just reading the
    > standard it says that such names are "unbound" (including the operator)
    > and become bound at template instantiation time. So I fail to see why
    > it even _could_ be correct to fail to compile this code; all the
    > information the compiler needs is there, when it needs it.
    >


    In this area I defer to EDG's reading of the standard.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Aug 10, 2003
    #14
  15. On Sun, 10 Aug 2003 16:10:53 +0100, "Simon Saunders" <> wrote:

    >On Sun, 10 Aug 2003 14:13:59 +0100, John Harrison wrote:
    >
    >> This code fails to compile on Comeau C++ and VC++ 7.1 (with language
    >> extensions disabled)
    >>
    >> template <class T>
    >> struct B
    >> {
    >> T b;
    >> };
    >>
    >> template <class T>
    >> struct D : B<T>
    >> {
    >> void f() { b = 1; }
    >> };
    >>
    >> int main()
    >> {
    >> D<int> x;
    >> x.f();
    >> }
    >>
    >> Error messages refer to 'b = 1;' with the message 'undefined identifier b'.
    >> Substituting this->b for b or making B a non-template class both make the
    >> code compile.
    >>
    >> What's going on here? I was so surprised when I saw this on VC++ that I
    >> assumed it was a compiler bug, but apparently not.
    >>
    >> john

    >
    >It's definitely not a compiler bug.


    How can you be sure of that?


    >HP's aCC compiler even tells you where
    >to look in the Standard:
    >
    >Error (future) 641: "xx.cc", line 16 # Undeclared variable 'b'. A variable
    > with the same name exists in a template base class, but is not visible
    > according to the Standard lookup rules (See [temp.dep], 14.6.2(3) in the
    > C++ Standard). You can make it visible by writing 'this->b'.
    > void f() { b = 3; }
    > ^


    According to §14.6.2/3 the base class scope is not examined _until_ the class
    is instantiated -- naturally, since the information required (type T) isn't
    present until then. And until then, 'b' is "unbound" according to §14.6.2/1.



    >There is an explanation of this rule in the book "C++ Templates - The
    >Complete Guide" by Vandevoorde and Josuttis (section 9.4.2).


    Could you please quote? The rule about not examining the base class
    scope until instantiation needs no explanation, really, so if that's
    what Jousittis explains it's irrelevant. The failure to compile this
    code sans name qualification does need an explanation, and the effect
    of qualification (on these compilers) needs to be rooted in the standard.
     
    Alf P. Steinbach, Aug 10, 2003
    #15
  16. On Sun, 10 Aug 2003 11:22:29 -0400, Pete Becker <> wrote:

    >Pete Becker wrote:
    >>
    >> "Alf P. Steinbach" wrote:
    >> >
    >> > If Visual C++ 7.1 also uses the EDG front-end then it's just one.

    >>
    >> Visual C++ 7.1 does not use the EDG front end.

    >
    >What I should have said is, do you have any reason to think that VC++
    >used EDG's front end? I have no information either way.


    Neither have I; if was an "if".
     
    Alf P. Steinbach, Aug 10, 2003
    #16
  17. On Sun, 10 Aug 2003 17:27:47 +0100, "Simon Saunders" <> wrote:

    >On Sun, 10 Aug 2003 15:41:25 +0000, Alf P. Steinbach wrote:
    >
    >> On Sun, 10 Aug 2003 16:10:53 +0100, "Simon Saunders"
    >> <> wrote:
    >>
    >>>On Sun, 10 Aug 2003 14:13:59 +0100, John Harrison wrote:
    >>>
    >>>> This code fails to compile on Comeau C++ and VC++ 7.1 (with language
    >>>> extensions disabled)
    >>>>
    >>>> template <class T>
    >>>> struct B
    >>>> {
    >>>> T b;
    >>>> };
    >>>>
    >>>> template <class T>
    >>>> struct D : B<T>
    >>>> {
    >>>> void f() { b = 1; }
    >>>> };
    >>>>
    >>>> int main()
    >>>> {
    >>>> D<int> x;
    >>>> x.f();
    >>>> }
    >>>> }
    >>>> Error messages refer to 'b = 1;' with the message 'undefined
    >>>> identifier b'. Substituting this->b for b or making B a non-template
    >>>> class both make the code compile.
    >>>>
    >>>> What's going on here? I was so surprised when I saw this on VC++ that
    >>>> I assumed it was a compiler bug, but apparently not.
    >>>>
    >>>> john
    >>>
    >>>It's definitely not a compiler bug.

    >>
    >> How can you be sure of that?
    >>
    >>
    >>>HP's aCC compiler even tells you where to look in the Standard:
    >>>
    >>>Error (future) 641: "xx.cc", line 16 # Undeclared variable 'b'. A
    >>>variable
    >>> with the same name exists in a template base class, but is not
    >>> visible according to the Standard lookup rules (See [temp.dep],
    >>> 14.6.2(3) in the C++ Standard). You can make it visible by writing
    >>> 'this->b'.
    >>> void f() { b = 3; }
    >>> ^

    >>
    >> According to §14.6.2/3 the base class scope is not examined _until_ the
    >> class is instantiated -- naturally, since the information required
    >> (type T) isn't present until then. And until then, 'b' is "unbound"
    >> according to §14.6.2/1.
    >>
    >>
    >>

    >
    >14.6.2/1 says that _dependent_ names are unbound until instantiation. The
    >point is that the name "b" in the definition of D<T>::f() is a
    >nondependent name according to the rules laid out in the Standard (whereas
    >"this->b" is dependent).


    Ah, this is opposite of Pete Becker's tentative usage of the term.

    The wording of the standard just become much clearer... ;-)

    Although the effect it specifies is counter-intuitive in the extreme;
    awkward and inconsistent name lookup, so incomprehensible that neither I,
    Victor Bazarow nor Pete Becker have fully grasped it, just to marginally
    optimize compilation. Donald Knuth was right. It's evil.


    >...
    >I'll do my best to summarize it. Nondependent names are looked up when the
    >template D is first encountered, not postponed until instantiation as is
    >the case for dependent names. The advantage of this approach is that
    >errors caused by missing symbols can be diagnosed earlier. It also
    >prevents surprises resulting from explicit specializations of the
    >dependent base class, e.g. consider this:
    >
    >#include <iostream>
    >
    >using namespace std;
    >
    >int b = 0;
    >
    >template <class T>
    >struct B
    >{
    > T b;
    >};
    >
    >template <class T>
    >struct D : B<T>
    >{
    > void f() { b = 3; }
    >};
    >
    >template <>
    >struct B<int>
    >{
    >};
    >
    >int main()
    >{
    > D<int> x;
    > x.f();
    > cout<<b<<endl;
    >}
    >
    >Older compilers (such as Visual C++ 6.0) that do not implement the current
    >rules will compile this and print out "3" when the program is executed,


    Isn't that right according to current rules? 'b' in D is, counter-intuitively
    and inconsistent with non-template code, bound to the global 'b'?


    >yet without the explicit specialization the output is "0".


    ?
     
    Alf P. Steinbach, Aug 10, 2003
    #17
  18. John Harrison

    Pete Becker Guest

    "Alf P. Steinbach" wrote:
    >
    > Although the effect it specifies is counter-intuitive in the extreme;
    > awkward and inconsistent name lookup, so incomprehensible that neither I,
    > Victor Bazarow nor Pete Becker have fully grasped it


    I haven't tried to, so that's not a meaningful data point.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Aug 10, 2003
    #18
  19. John Harrison

    Pete Becker Guest

    "Alf P. Steinbach" wrote:
    >
    > On Sun, 10 Aug 2003 13:51:17 -0400, Pete Becker <> wrote:
    >
    > >"Alf P. Steinbach" wrote:
    > >>
    > >> Although the effect it specifies is counter-intuitive in the extreme;
    > >> awkward and inconsistent name lookup, so incomprehensible that neither I,
    > >> Victor Bazarow nor Pete Becker have fully grasped it

    > >
    > >I haven't tried to, so that's not a meaningful data point.

    >
    > You have years of experience with C++, you're a smart guy, and you work
    > at Dinkumware.


    None of which give me any significant experience with the details of
    two-phase lookup. I haven't studied it, so the fact that I don't
    understand it says very little about its comprehensibility. Like most
    powerful tools, programming languages require study and practice.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Aug 11, 2003
    #19
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alexandre Tolmos
    Replies:
    1
    Views:
    382
    Victor Bazarov
    Aug 8, 2003
  2. Pete
    Replies:
    4
    Views:
    411
  3. flopbucket
    Replies:
    2
    Views:
    442
    Andrey Tarasevich
    Jun 23, 2006
  4. chhenning
    Replies:
    5
    Views:
    383
    chhenning
    Feb 13, 2008
  5. Bhawna
    Replies:
    7
    Views:
    492
    Bhawna
    Aug 26, 2008
Loading...

Share This Page