g++ 3.4 and protected member variable

ahwkong · 04-27-2005, 06:13 PM

I have these following files:

t.h

Code:

namespace nc{

    template<typename T>
    class Base {
        T hello;

        protected:
            int test1;
    };

    template<typename T>
    class Next: public Base<T>{

        int test();
    };
};

#include "t.tmpl"

t.tmpl

Code:

template<typename T>
int nc::Next<T>::test(){
    return test1;
}

test.cpp

Code:

#include "t.h"

g++ complaints that, inside Next<T>::test(), test1 is undeclared. However, it is a protected member varibale of base class. It supposed to be visible to the derived class, right?

What's wrong?

rununix · 04-27-2005, 08:20 PM

try adding
using namespace nc;

wild guess since you haven't given the rest of code

ahwkong · 04-27-2005, 11:47 PM

I have given all the source. It is an example to demonstrate the case. It can be compiled, although the program does not do anything.

Code:

g++ test.cpp

deiussum · 04-28-2005, 08:26 AM

It compiles fine with g++ 3.3.3 (cygwin special). I don't have 3.4 installed anywhere, so I can't try it with that myself. Something definitely seems odd about that.

BTW, you need the -c flag to compile the example. Otherwise it will try to link in a non-existent main function...

ahwkong · 04-28-2005, 09:02 AM

deiussum,

You are right about the -c flag, but in my case, gcc 3.4.2, the syntax error stops it to go any further to the point of linking, so it does not really matter...

Maybe let me reproduce the error messages here:

Code:

In file included from t.h:18,
                 from test.cpp:1:
t.tmpl: In member function `int nc::Next<T>::test()':
t.tmpl:3: error: `test1' undeclared (first use this function)
t.tmpl:3: error: (Each undeclared identifier is reported only once for each function it appears in.)

deiussum · 04-28-2005, 03:50 PM

Yeah, I didn't mean to say that using the -c flag would take care of your problem, just wanted to clarify that for anyone else trying to compile your example code.

Just for curiosity, what happens when you change the protection level of test1 to public? You are right that it you should be able to access it as protected, but I can't reproduce the error, and don't really have the time to get g++ 3.4.

ahwkong · 04-28-2005, 04:22 PM

Sure I understand why you mentioned the flag! That's would help other readers of the thread. :-)

The problem is I am working on a design which requested the field to be protected. That's why I have to ask for an answer :-)

deiussum · 04-28-2005, 04:34 PM

Yep. I understand that you want it to be protected, but I'm just curious if you will still get the error if you switch it to public. If you do, it could be some problem unrelated to its protection level. You SHOULD be able to access it from the derived class as a protected variable, but you can't for some reason. The same code compiles fine for me with 3.3.3 so I can't reproduce your problem to try and figure out why it's occuring.

ahwkong · 04-28-2005, 04:51 PM

You have a point. I switched to public and the same error appears... Certianly it is least expected...

I had read the g++ change file before starting this thread but found nothing really related to it. I probably should go back and read again.

Hivemind · 04-28-2005, 08:07 PM

Using g++ 4.0.0, changing the file t.tmpl to:

Code:

template<typename T>
int nc::Next<T>::test(){
    return Base<T>::test1; /* Note: fully qualified name. */
}

makes the program compile and link. I also removed an unnecessary ; after the closing } in the namespace and added include guards (very important for templates). My test program was:

Code:

$ cat main.cpp

Code:

#include "t.hpp" /* I use the .hpp extension for c++-headers, .h for c-headers. */

int main()
{
   nc::Next<int> duh;

   return 0;
}

deiussum · 04-29-2005, 08:13 AM

It's interesting that 3.4+ makes you fully qualify the name in this case. I wonder how many C++ projects there are that won't compile because of this. I know I seldom fully qualify my member variables unless there is some ambiguity, or I need to call the base class method in a virtual method.

ahwkong · 04-29-2005, 04:26 PM

Thanks, Hivemind!

Agree with deiussum... It is going to break a lot of application I believe. Before g++3.4, the principle of template is (the way i understand it) "specify if only there is ambiguity"

Besides, it is very inflexible. If I were to change the base class, I have to do a lot of text substitution. Not a nice solution.

Even use of -fpermissive does not get rid of this as an error. :-(