Template trouble

[Pelle19]

I wonder why I get a compiler error if I uncomment the two operator definitions?
Also I wonder why I get a compiler error on v.push_back(5) if I change the line "SafeVector<int> v(10);" to "SafeVector<int> v();" ?
I'm using Linux Mint and g++. I would be so grateful if someone could help me.

#include <iostream>
#include <vector>
using namespace std;

template<class T>class SafeVector : public vector<T> {
public:
SafeVector():vector<T>() { }
SafeVector(int s) : vector<T> (s) { }
// T& operator[](int i) {return at(i);}
// const T& operator[](int i) const {return at(i);}
};

int main() {
SafeVector<int> v(10);
v.push_back(5);
cout << v[0]<<endl;

return 0;
}

[guestgulkan]

T& operator[](int i) {return at(i);}
 const T& operator[](int i) const {return at(i);}

When initially parsing the template, the compiler don't know what the at function is. It cannot know that that the base class contains a function called at .

You can do the following:

1. use the this pointer
2. use the base class scope resolution operator vector<T>::

template<class T>class SafeVector : public vector<T> 
{
    public:
    SafeVector():vector<T>() { }
    SafeVector(int s) : vector<T> (s) { }
     T& operator[](int i) {return this->at(i);} // using this->
     const T& operator[](int i) const {return vector<T>::at(i);} //using base class sope resolution
}

[1yR4jE8b]

I'd just like to point out that you should not be extending from STL containers: they do not have virtual destructors.

[doug4]

To answer the OP's second question, when you removed the argument but left the parentheses from the SaveVector<int> constructor call, you inadvertantly changed the definition of v from a SafeVector to a function taking no argument and returning a SafeVector. By removing the parentheses you will get what you are looking for.

SafeVector<int> v;

Edit: fixed spelling

[ne555]

I'd just like to point out that you should not be extending from STL containers: they do not have virtual destructors.

As long as you don't use polymorphism, ¿why is that a problem?

[1yR4jE8b]

1. The STL wasn't designed to be inherited (no virtual destructors), limiting yourself to non-polymorphic use at first is a bad idea because you could: forget later on, annoy other people that use your code, develop bad habits etc...

2. No protected members, so you aren't gaining anything by inheriting.

3. Probably a better idea to use composition when a class can't be used polymorphically.

4. You can probably gain exactly what you need without inheritance using <algorithm> and functors/free functions (preferably using templates) and just using regular std::vector, and you will probably definitely have less bugs and finish the code faster.

5. Not everything in C++ needs to be object oriented, hence why STL algorithms are free-functions.

6. Writing code to take advantage of iterators and STL algorithms is much more elegant, reusable and easier than dealing with inheritance.

7. Pretty much just a bad idea in general, it seems hackish, and professionals generally frown upon it because it makes their lives more difficult and is error-prone.

[jsmith]

I want to point out that guestgulkan's answer is not technically correct. If the base class were a non-template (and contained an at() method), the code would compile just fine. The compiler has to know what the base class has in it.

The problem is that there is blurb in the standard that says that use of members (functions and data) of a templated base class have to be fully qualified in the derived class.

[guestgulkan]

I stand technically corrected

[dearvivekkumar]

Please read Scott mayer(Effective c++)

Item 43: Know how to access names in templatized base classes

http://my.safaribooksonline.com/book/programming/cplusplus/0321334876/templates-and-generic-programming/ch07lev1sec3

[guestgulkan]

I knew about this - I have mentioned it in other questions on the same subject - it
just slipped my mind this time around.