Thread: problem with templates and parent variables accessing

  1. #1
    Registered User
    Join Date
    Nov 2007
    Posts
    11

    problem with templates and parent variables accessing

    Hi, I don't know why my chiled class cannot access parent's variables.
    I am using mingw 5.1.3 toolchain.

    This works:

    Code:
    #include <iostream>
    
    using namespace std;
    
    template< class T >
    class first
    {
    protected:
        int abc;
        T   def;
    public:
        first()
        {
            abc = 3;
            def = 4;
        }
    };
    
    class second : first< int >
    {
    public:
        int get_abc()
        {
            return abc;
        }
        //
        int get_def()
        {
            return def;
        }
    };
    
    int main()
    {
        second a;
        //
        cout << a.get_abc() << endl;
        cout << a.get_def() << endl;
        //
        return 0;
    }
    but if I change the child to a template class it doesn't:

    Code:
    #include <iostream>
    
    using namespace std;
    
    template< class T >
    class first
    {
    protected:
        int abc;
        T   def;
    public:
        first()
        {
            abc = 3;
            def = 4;
        }
    };
    
    template< class T >
    class second : first< T >
    {
    public:
        T get_abc()
        {
            return abc;
        }
        //
        T get_def()
        {
            return def;
        }
    };
    
    int main()
    {
        second<int> a;
        //
        cout << a.get_abc() << endl;
        cout << a.get_def() << endl;
        //
        return 0;
    }
    I get errors that abc and def weren't declared in this scope.

    Does anyone know a way to overcome this problem( but still keep the hierarchy like ...child2: child1< template > : parent< template > and not move the variables from parent to chiled )?

    Thanks.
    Domen

  2. #2
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #3
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Wow, that's pretty strange.
    It looks to me to be either a bug in compilers that don't allow it, or in the standard if that's what it says.

  4. #4
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    That's what the standard says, and it's a concession to compiler writers, not a bug. Doing it any other way would lead to even more complex compilers, slower compilation, and perhaps even a few edge cases that are simply ambiguous.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  5. #5
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    We may call it what we will, but if the standards says it isn't allowed, then we must abide by the rules. Thankfully, there is a very solution available, by just using this->.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #6
    Registered User
    Join Date
    Nov 2007
    Posts
    11
    Thanks!

    This makes the code a bit uglyer but if it's in the standard then I guess that it's so for a good reason.

    Regards, Domen.

  7. #7
    Use this: dudeomanodude's Avatar
    Join Date
    Jan 2008
    Location
    Hampton, VA
    Posts
    391
    All right, I'm just kidding but:
    I think "this->" was created by the guys who designed the compilers to fix errors like this one, nothing more.

    But seriously:
    Unless absolutely necessary, I don't use the this-> pointer. Just a point of personal preference I guess, but when I see code littered with this->, I cringe...

  8. #8
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    Quote Originally Posted by CornedBee View Post
    That's what the standard says, and it's a concession to compiler writers, not a bug. Doing it any other way would lead to even more complex compilers, slower compilation, and perhaps even a few edge cases that are simply ambiguous.
    Any idea what the specific implications were?

  9. #9
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    According to the FAQ I linked to:
    Here's the rule: the compiler does not look in dependent base classes (like B<T>) when looking up nondependent names (like f).
    So my guess is that the concession is to relieve the compiler of the need to search in dependent base classes when looking up non-dependent names.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  10. #10
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    Yes, but when would that be so prohibitively expensive?

  11. #11
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by dudeomanodude View Post
    All right, I'm just kidding but:
    I think "this->" was created by the guys who designed the compilers to fix errors like this one, nothing more.
    "this->" wasn't created to solve this problem. It would have worked anyway.

  12. #12
    Use this: dudeomanodude's Avatar
    Join Date
    Jan 2008
    Location
    Hampton, VA
    Posts
    391
    "this->" wasn't created to solve this problem. It would have worked anyway.
    I know, i was just kidding.

  13. #13
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Quote Originally Posted by robwhit View Post
    Yes, but when would that be so prohibitively expensive?
    Actually, I confused this issue with a similar one. This one is about not introducing subtle bugs, not about compiler performance or complexity. Consider this apparently harmless piece of code.
    Code:
    void foo()
    {
      // Do something.
    }
    
    template <typename T>
    class bar
    {
    public:
      void whatever();
    };
    
    template <typename T>
    class barder : public bar<T>
    {
    public:
      void something()
      {
        foo();
      }
    };
    What's the effect of this code? It calls ::foo(), of course, right? Right?


    But what if someone comes along and adds a specialization to bar:
    Code:
    template <>
    class bar<sometype>
    {
    public:
      void whatever();
      void foo(); // hehe
    };
    If dependent names are looked up for unqualified names, barder<sometype>::something() would - without doubt very surprisingly for the author - call bar<sometype>::foo() instead of ::foo().


    That's the actual reason for this little quirk. The performance/complexity issue is about the typename and template keywords.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  14. #14
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    Thanks!

Popular pages Recent additions subscribe to a feed