error compiling

Code:

#include <iostream>
#include <vector>

using namespace std;

struct Entry {
       string name;
       int number;
};

void add_entries(int n, vector<Entry> &vec)
{
     vec.resize(vec.size() + n);
}

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

It seems like i cant compile this... The error is in the bolded line inside the template class Vec:

`template<class _Tp, class _Alloc> class std::vector' used without template parameters

I dont know why?

I get no error. But do note that it's generally a bad idea to inherit from a standard library container. They do not play well with inheritance.
Furthermore, a vector takes at least two template parameters, as you can see from the error. You may want to change that.

You should try:

Code:

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

This way you are informing the compiler that the at() method comes from the templated base class (since it obviously doesn't come from the current class). At the point where you are getting the error, the compiler is not yet instantiating the base class, and therefore it does not know that vector<T> has an at method.

The explanation is here: Why am I getting errors when my template-derived-class uses a member it inherits from its template-base-class?

(Elysia, you love heavily templated code, but you are using MSVC which is known not to handle templates the way the gods of C++ intended... )

Originally Posted by anon

(Elysia, you love heavily templated code, but you are using MSVC which is known not to handle templates the way the gods of C++ intended... )

I know, but unfortunately, GCC is not an option at this time.
(And I don't know if it's possible to integrate it into the VS IDE.)

Elysia's right though, you aren't supposed to inherit from the standard library. The only reason IIRC is because none of the libraries use virtual destructors. Say, vector throws an exception and isn't properly destructed after your object.

Composition would make as much sense.

Code:

template <typename type> class MyArray
{

public:

MyArray () { }
MyArray (size_t size) : m_impl (size) { }
const T& operator[] (size_t i) const { return m_impl.at (i); }
T& operator[] (size_t i) { return m_impl.at (i); }

private:

vector<type> m_impl;

};

Originally Posted by whiteflags

Elysia's right though, you aren't supposed to inherit from the standard library. The only reason IIRC is because none of the libraries use virtual destructors. Say, vector throws an exception and isn't properly destructed after your object.

That is not illegal, tho, it's a simple caveat. This is akin to saying you aren't suppose to write off the end of an array, so you should not use arrays period.

So the caveat is:
[20] Inheritance -- virtual functions, C++ FAQ Lite

Ie, if you inherit from vector and call the derived class myvec, don't do this:

Code:

vector<blah> *eg = new myvec();
delete(eg);

Without a virtual destructor, calling delete on a pointer to a base class pointing to a derived class will only cause the base class's constructor to be called. This is since the compiler cannot know that the base class holds a pointer to a derived class.
Therefore, the base class destructor must be virtual.

Originally Posted by Elysia

Therefore, the base class destructor must be virtual.

No, therefore either:
1) Do not instantiate using a base class pointer, OR
2) Do rely on a meaningful destructor.

Code:

using namespace std;

class test : public string {
	public:
		test(string in) {
			assign(in);
		}
		~test() {
			cout << "Goodbye!\n";
		}
};

int main() {
	string *nums = new test("whatever");
	delete(nums);
	return 0;
}

The destructor is not called unless you change "string *nums" to "test *nums".

So you can inherit from the STL, just be aware of this issue!

The STL classes have other woes too, such as private members instead of protected.
On a side note, this is why I always make my non-public members protected instead of private unless I have a very good reason not to.
I haven't used private for I don't know how long.