inheriting std::vector

[VeganFanatic]

a while ago I wrote a vector template to assist in a project, it works OK. I was considering the effect inheriting the std::vector and make all of the functionality available and simply attach my new functionality on top of that. Is this practical? Here is the vector as it stands today. template <class base> class vector { public: std::vector<base> data; friend class matrix<base>; vector operator+(const vector &that) { // parallelogram law vector ret; assert(this->data.size() == that.data.size()); ret.resize(this->data.size()); #pragma omp parallel for for (int i = 0; i < this->data.size(); i++) ret.data[i] = this->data[i] + that.data[i]; return ret; } vector operator-(vector that) { // parallelogram law vector ret; assert(this->data.size() == that.data.size()); ret.resize(this->data.size()); #pragma omp parallel for for (int i = 0; i < this->data.size(); i++) ret.data[i] = this->data[i] - that.data[i]; return ret; } vector operator* (base &that) { // scalar product vector ret; ret.resize(this->data.size()); #pragma omp parallel for for (int i = 0; i < this->data.size(); i++) ret.data[i] = this->data[i] * that; return ret; } double operator* (vector &that) { // dot / inner product double ret; #pragma omp parallel for for (int i = 0; i < this->data.size(); i++) ret += this->data[i] * that.data[i]; // sum of products of complex numbers is real return ret; } vector operator/ (base &that) { // scalar division vector ret; ret.resize(this->data.size()); #pragma omp parallel for for (int i = 0; i < this->data.size(); i++) ret.data[i] = this->data[i] / that; return ret; } vector operator= (vector &that) { // assignment operator for (int i=0; i < that.data.size(); i++) this->data[i] = that.data[i]; return *this; } base& operator[] (size_t index) { return this->data[index]; } bool operator== (vector &that) { bool temp = true; for (int i=0; i < that.data.size(); i++) if (this->data[i] != that.data[i]) temp = false; return temp; } // the norm is the vector length base norm(void) { base result = (base)0.0; #pragma omp parallel for for (int i = 0; i < this->data.size(); i++) { result += this->data[i] * this->data[i]; // sum of products of complex numbers is real } retu

[Aescleal]

The general concensus is don't inherit from an STL collection - they're not designed for it. The two ways I'd recommend going about extending an STL collection is either bundle it up in another class (which you've done) OR just write free functions to do the extended functionality. From your example it looks like you want a geometric vector and not a collection of doodads that might or might not have some geometric relationship. Incidentally if you want to continue using containment the way you have make the std::vector private. You really don't want a class exposing data through it's public interface, it's really hard to test and some idiot will maul it for you - even if that idiot turns out to be you several months down the line when you've forgotten what you did. Cheers, Ash

[Chris Losinger]

it might work, but in general you should avoid inheriting directly from STL containers, if you can. the reason is that these containers do not have virtual destructors, and that may expose you to memory leaks. http://www.codeguru.com/forum/archive/index.php/t-267641.html[^]

image processing toolkits | batch image processing

[VeganFanatic]

I guess I will need to add more accessors then to make it resemble the std::vector My goal is to resemble the std::vector and bolt on some linear algebra

http://www.contract-developer.tk

[VeganFanatic]

I find that adding: template <class base> class vector : std::vector<base> does not seem to provide a great deal of change? So what impact if any does inheriting the object get me?

http://www.contract-developer.tk

[Chris Losinger]

VeganFanatic wrote:

So what impact if any does inheriting the object get me?

again, STL containers do not provide virtual destructors[^]

image processing toolkits | batch image processing

[VeganFanatic]

Should I simply add more code and add formal constructors and destructors? Go for base* data construct instead?

http://www.contract-developer.tk

[Chris Losinger]

VeganFanatic wrote:

Should I simply add more code and add formal constructors and destructors?

no matter what you do, because STL containers do not have virtual dtors, the destructor in your derived class will not be called. http://www.devx.com/tips/Tip/13509[^]

image processing toolkits | batch image processing

[Stephen Hewitt]

This is only an issue if he deletes the object through the base class.

Steve

[Chris Losinger]

well, i provided as many links to detailed explanations as i could stand to look up.

image processing toolkits | batch image processing

[Emilio Garavaglia]

Chris, those links are "things to be noted" not "the Bible". The STL itself is designed by inheriting between classes that don't have virtual destructor. Think to iofstream versus istream and ostream STL containers don't have virtual destructors because they are designed to be non-polymophic and to exist into a closed scope. If you respect this, that means don't do things like (pseudocode)

vector* p = new myvector;
delete p; //worng: will destroy only "vector" not "myvector"

but just

{
myvector v;
//whatever you want with v, including vector functionality
}

you are in any case in a right position.

2 bugs found. > recompile ... 65534 bugs found. :doh:

[Chris Losinger]

i thought it would be better to tell the OP where to find relevant information, rather than to try explaining the entire topic and trying to find out which bits he needed to specifically worry about.

image processing toolkits | batch image processing