override vector::insert

[paradoxresolved]

Can someone please show me how to override vector::insert?

I've tried:
template <class T> iterator MyVector::insert ( iterator it, const T& x )
{
vector<T>::insert(it,x);
// my code here
}

However, it tells me that I need more parameters for iterator, but I'm not sure what.

MyVector is derived from vector.

Thank you.

[GNiewerth]

STL containers are not intended to be derived from because they don´t have a virtual destructor. Use composition instead to reuse std::vector. Your class needs to wrap its own methods around vector´s methods.

template<typename T>
class myvector
{
   std::vector<T> Impl_;

public:
   // typedef iterator type
   typedef typename std::vector<T>::iterator iterator;
   typedef typename std::vector<T>::const_iterator const_iterator;


   iterator insert( iterator it, const T& op )
   {
      return Impl_.insert( Impl_.begin(), op );
   }
}

Please note that most methods of vector come in pairs to ensure const correctness.

[paradoxresolved]

Thanks! I'll give it a shot.

[paradoxresolved]

Rats. I'm going to have to recreate the interface for .at(..), .push_back(..), .pop_back(), .size(), as well as .insert(..), and perhaps a few others that I'm not readily thinking of. . .

.at(..) returns const_reference, which apparently isn't the same thing as T&.

Is the NO way to force the destructor for vector, so that I can keep my vector class as derived?? What if I .clear() the vector during the derived destructor?

[Paul McKenzie]

Rats. I'm going to have to recreate the interface for .at(..), .push_back(..), .pop_back(), .size(), as well as .insert(..), and perhaps a few others that I'm not readily thinking of. . .

.at(..) returns const_reference, which apparently isn't the same thing as T&.

What exactly are you trying to accomplish by deriving from std::vector?

Is the NO way to force the destructor for vector,

What do you mean by "force the destructor"?

so that I can keep my vector class as derived??

Since you derived from vector, when your object is destroyed, vector is destroyed. There is no such thing as destroying a parent and having the derived remain intact.

Regards,

Paul McKenzie

[souldog]

for example. Really not much to do

#include <vector>

template<typename T>
class VectorHolder
{
public:
	virtual ~VectorHolder(){}

	void clear() {TVector_.clear();}
	bool empty() const {return TVector_.empty();}
	std::vector<T>::size_type size() const {return TVector_.size();}
	std::vector<T>::const_iterator begin() const {return TVector_.begin();}
	std::vector<T>::iterator begin() {return TVector_.begin();}
	std::vector<T>::const_iterator end() const {return TVector_.end();}
	std::vector<T>::iterator end() {return TVector_.end();}

	std::vector<T>::const_reference operator[](const std::vector<T>::size_type i) const {return TVector_[i];}
	std::vector<T>::reference operator[](const std::vector<T>::size_type i) {return TVector_[i];}
	std::vector<T>::const_reference at(const std::vector<T>::size_type i) const {return TVector_.at(i);}
	std::vector<T>::reference at(const std::vector<T>::size_type i) {return TVector_.at(i);}

protected:
	std::vector<T> TVector_;
};

[Philip Nicoletti]

1.

.at(..) returns const_reference, which apparently isn't the same thing as T&.

???? there are two signatures for at()... one return a reference and
one returns a const reference

2. What exactly are you trying to accomplish in overriding insert() ?
The normal way is composition.

3. I think that you could use PRIVATE inheritance ... but you
would need to provide implementations for the functions that
you want.

[paradoxresolved]

Ok, I have tried this:

vector<T>::reference at(uint index);

template<typename T> vector<T>::reference MyVector<T>::at(uint index)
{
	return this_vector.at(index);
}

It then returns the error:
error C2662: 'at' : cannot convert 'this' pointer from 'const class MyVector<class boost::shared_ptr<class MyObject> >' to 'class MyVector<class boost::shared_ptr<class MyObject> > &'

I see that there are two versions of .at(..). Is it confusing the one I want??

Why do I want to derive a class from vector? It simplifies my code considerably. Long story. Making it a member of another class works just as well, I suppose. I just can't get the interface to play nicely now.

[MrDoomMaster]

 
template< typename t_type >
class MyVector : public std::vector<t_type>
{
public:
	~MyVector()
	{
		std::vector<t_type>::~vector();
	}

	iterator insert( iterator it, const t_type& x )
	{
		std::vector<t_type>::insert(it,x);
		// my code here
	}
};

*dodges all of the sharp weapons being thrown at him*

[Paul McKenzie]

Why do I want to derive a class from vector? It simplifies my code considerably.

How does it simplify your code? Show me an example of where code is simplified by deriving from vector. Deriving because it saves typing is not justification for derivation.

There is something in your derived class that wasn't provided by vector, else you wouldn't have derived from it. Whatever those things are, you could more than likely have implemented them using algorithm or some other functions that worked on vector, or iterators in general.

Regards,

Paul McKenzie

[Paul McKenzie]

 
template< typename t_type >
class MyVector : public std::vector<t_type>
{
public:
	~MyVector()
	{
		std::vector<t_type>::~vector();
	}

This code is ill-formed. The "natural" destruction process will already destroy the parent, and then you're calling it again, causing undefined behaviour.



Regards,

Paul McKenzie

[MrDoomMaster]

Oh, yeah! Good catch. I had a brain fart.

[paradoxresolved]

I'm wrapping a class around vector such that, when this class is a member of a parent class, it automatically stores a pointer to the parent in the child object that is "pushed back" in the vector. It forms a tree that can search down to the root.

Otherwise, I have to go through all my code and set the parent at each and every instance of "push_back." It's highly time-consuming, messy, and error-prone.

[paradoxresolved]

I'm still getting the error with the ".at(..)" interface. MSDN says there are two .at(..) functions in vector

reference at(size_type pos);
const_reference at(size_type pos) const;

It seems the second of the two is firing off, when the first is what I need.

My .at(..) function is:

vector<T>::reference at(uint i) 
{
return TVector_.at(i);
}

Do I need to define both versions?

[laserlight]

It seems the second of the two is firing off, when the first is what I need.

That will only happen if the current object is const in the given context.

Do I need to define both versions?

Yes.