Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > accessing members of a templated base class

Reply
Thread Tools

accessing members of a templated base class

 
 
John Harrison
Guest
Posts: n/a
 
      08-10-2003
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


 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      08-10-2003
"John Harrison" <(E-Mail Removed)> 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


 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      08-10-2003
On Sun, 10 Aug 2003 14:13:59 +0100, "John Harrison" <(E-Mail Removed)> 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.

 
Reply With Quote
 
Pete Becker
Guest
Posts: n/a
 
      08-10-2003
"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)
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      08-10-2003
On Sun, 10 Aug 2003 10:12:08 -0400, Pete Becker <(E-Mail Removed)> 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.

 
Reply With Quote
 
John Harrison
Guest
Posts: n/a
 
      08-10-2003
> >
> > 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


 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      08-10-2003
On Sun, 10 Aug 2003 15:47:03 +0100, "John Harrison" <(E-Mail Removed)> 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.

 
Reply With Quote
 
Pete Becker
Guest
Posts: n/a
 
      08-10-2003
"Alf P. Steinbach" wrote:
>
> On Sun, 10 Aug 2003 10:12:08 -0400, Pete Becker <(E-Mail Removed)> 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)
 
Reply With Quote
 
Kristoffer Vinther
Guest
Posts: n/a
 
      08-10-2003
"Pete Becker" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "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


 
Reply With Quote
 
Simon Saunders
Guest
Posts: n/a
 
      08-10-2003
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).

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Accessing derived class members from base class Bhawna C++ 7 08-26-2008 11:03 AM
Defining templated member function outside templated class chhenning C++ 5 02-13-2008 07:36 PM
accessing base class members when base is template flopbucket C++ 2 06-23-2006 01:40 AM
What's wrong here? Accessing members of a templated base class Pete C++ 4 07-22-2004 02:26 PM
Accessing data members from templated copy constructor Alexandre Tolmos C++ 1 08-08-2003 01:21 PM



Advertisments