How to use the iterator from base class in a derived class?

[wangxiaohu]

I am trying to write a class myVector based on std::vector and add
only a sort method. The sort method needs to access the array stored
in the base class using iterator. I have following draft code. However
it never compile. Can anyone take a look and tell me how to fix it?
Thanks!

#include <vector>
#include <iostream>

using namespace std;

template <typename Tclass myVector : public vector<T>
{
public:
void Sort();
};

template <typename Tvoid Sort<T>::Sort()
{
if (this.size() < 2)
{
return;
}

vector<T>::iterator i;

for (i = this.begin(); i != this.end(); i++)
{
//rest part ignored....
}
}

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2007-10-18 09:29, wangxiaohu wrote:

I am trying to write a class myVector based on std::vector and add
only a sort method. The sort method needs to access the array stored
in the base class using iterator. I have following draft code. However
it never compile. Can anyone take a look and tell me how to fix it?
Thanks!

#include <vector>
#include <iostream>

using namespace std;

template <typename Tclass myVector : public vector<T>

The general advice is to not inherit from the standard containers,
instead create a class that wraps the container.

{
public:
void Sort();
};

template <typename Tvoid Sort<T>::Sort()

template <typename Tvoid <myVector<T>::sort()

{
if (this.size() < 2)

this->size()

This is a pointer to the current object, you need to use the dereference
operator (->) when accessing members of the current object.

--
Erik Wikström

[Kai-Uwe Bux]

wangxiaohu wrote:

I am trying to write a class myVector based on std::vector and add
only a sort method.

BadIdea(tm). That is abuse of inheritance. You should use a free standing
function instead:

template < typename T, typename A >
void sort_vector ( std::vector<T,A& sequence ) {
std::sort( sequence.begin(), sequence.end() );
}

or maybe even more generic:

template < typename Container >
void sort_sequence ( Container & sequence ) {
std::sort( sequence.begin(), sequence.end() );
}

or with a concept check:

template < typename Container >
void sort_sequence
( Container & sequence,
typename enable_if
< is_sequence< Container >::value, void* >::type = 0 ) {
std::sort( sequence.begin(), sequence.end() );
}
There are some cases where public inheritance from std::vector<is
justified. This does not look like one of them.

The sort method needs to access the array stored
in the base class using iterator. I have following draft code. However
it never compile. Can anyone take a look and tell me how to fix it?
Thanks!

#include <vector>
#include <iostream>

using namespace std;

Don't put using directives in header files. Your decision to pull all
identifiers from the standard namespace is inflicted upon every user of
your class. That is very intrusive.

template <typename Tclass myVector : public vector<T>
{
public:
void Sort();
};

template <typename Tvoid Sort<T>::Sort()

Shouldn't that be something like

template <typename T>
void myVector::Sort()

{
if (this.size() < 2)
{
return;
}

vector<T>::iterator i;

You would need to say

typename std::vector<T>::iterator i;

The keyword here is "dependent name".

>
for (i = this.begin(); i != this.end(); i++)
{
//rest part ignored....
}
}

BTW: why are you doing your own sort algorithm? any why only for vectors? It
is _very_ hard to beat std::sort() from the header <algorithm>.
Best

Kai-Uwe Bux

[wangxiaohu]

I just want to see if I can add a Sort() method to the existing vector
container.

What you've shown is write a individual function, which does work for
the purpose, but does not answer my question.

But really thanks to your detailed example!

wxh

On 10 18 , 1 22 , Kai-Uwe Bux <[e-mail]:

wangxiaohu wrote:

I am trying to write a class myVector based on std::vector and add
only a sort method.

BadIdea(tm). That is abuse of inheritance. You should use a free standing
function instead:

template < typename T, typename A >
void sort_vector ( std::vector<T,A& sequence ) {
std::sort( sequence.begin(), sequence.end() );
}

or maybe even more generic:

template < typename Container >
void sort_sequence ( Container & sequence ) {
std::sort( sequence.begin(), sequence.end() );
}

or with a concept check:

template < typename Container >
void sort_sequence
( Container & sequence,
typename enable_if
< is_sequence< Container >::value, void* >::type = 0 ) {
std::sort( sequence.begin(), sequence.end() );
}

There are some cases where public inheritance from std::vector<is
justified. This does not look like one of them.

The sort method needs to access the array stored
in the base class using iterator. I have following draft code. However
it never compile. Can anyone take a look and tell me how to fix it?
Thanks!

#include <vector>
#include <iostream>

using namespace std;

Don't put using directives in header files. Your decision to pull all
identifiers from the standard namespace is inflicted upon every user of
your class. That is very intrusive.

template <typename Tclass myVector : public vector<T>
{
public:
void Sort();
};

template <typename Tvoid Sort<T>::Sort()

Shouldn't that be something like

template <typename T>
void myVector::Sort()

{
if (this.size() < 2)
{
return;
}

vector<T>::iterator i;

You would need to say

typename std::vector<T>::iterator i;

The keyword here is "dependent name".

for (i = this.begin(); i != this.end(); i++)
{
//rest part ignored....
}
}

BTW: why are you doing your own sort algorithm? any why only for vectors? It
is _very_ hard to beat std::sort() from the header <algorithm>.

Best

Kai-Uwe Bux

[Kira Yamato]

On 2007-10-20 16:58:47 -0400, Tristan Wibberley <ma********@maihem.orgsaid:

>
On Thu, 2007-10-18 at 08:04 +0000, Erik Wikström wrote:

>The general advice is to not inherit from the standard containers,
instead create a class that wraps the container.

I'd heard that was because somebody might use a reference to your object
with type std::vector<...>& and use all the wrong functions.

This doesn't make sense. I thought the whole point of Object-Oriented
Programming is that polymophisms are encouraged as a coding structure.

If a derived class can potentially ``damaged'' the integrity of the
base class, then as the designer of the base class he shouldn't have
allowed his methods be declared virtual (so that the derived class
could not override it). If so, how then can any reference of the base
class be using any wrong methods supplied by the derived class?

>
Is there any other problem that makes that a bad idea too?

Yea, I like to know too.

--

-kira

[Tristan Wibberley]

On Sat, 2007-10-20 at 18:02 -0400, Kira Yamato wrote:

... I thought the whole point of Object-Oriented
Programming is that polymophisms are encouraged as a coding structure.

Standard containers are not object oriented then.

In the standard C++ library it's basically locale and iostreams related
stuff that is OO (or at least has OO aspects), the rest is just abstract
data types.

--
Tristan Wibberley

Any opinion expressed is mine (or else I'm playing devils advocate for
the sake of a good argument). My employer had nothing to do with this
communication.

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2007-10-21 00:02, Kira Yamato wrote:

On 2007-10-20 16:58:47 -0400, Tristan Wibberley <ma********@maihem.orgsaid:

>>
On Thu, 2007-10-18 at 08:04 +0000, Erik Wikström wrote:

>>The general advice is to not inherit from the standard containers,
instead create a class that wraps the container.

I'd heard that was because somebody might use a reference to your object
with type std::vector<...>& and use all the wrong functions.

This doesn't make sense. I thought the whole point of Object-Oriented
Programming is that polymophisms are encouraged as a coding structure.

If a derived class can potentially ``damaged'' the integrity of the
base class, then as the designer of the base class he shouldn't have
allowed his methods be declared virtual (so that the derived class
could not override it). If so, how then can any reference of the base
class be using any wrong methods supplied by the derived class?

None of the standard library containers have any virtual functions, most
notably the destructor is not virtual. This is because they were not
designed to be inherited from.

>Is there any other problem that makes that a bad idea too?

Yea, I like to know too.

If the base class does not have a virtual destructor the derived class's
destructor will not be run when deleting a base class pointer pointing
to a derived object.

--
Erik Wikström

[Tristan Wibberley]

On Sun, 2007-10-21 at 12:00 +1300, Ian Collins wrote:

Tristan Wibberley wrote:

On Thu, 2007-10-18 at 08:04 +0000, Erik Wikström wrote:

The general advice is to not inherit from the standard containers,
instead create a class that wraps the container.

I'd heard that was because somebody might use a reference to your object
with type std::vector<...>& and use all the wrong functions. What about
private inheritance?

Is there any other problem that makes that a bad idea too?

Standard containers don't have virtual destructors.

That wouldn't be a concern with private inheritance since any pointer to
an instance of the container that might be "delete"ed *must* be
pointer-to-derived class and the correct destructor will be called -
unless the derived class exports a pointer to the base class (which
would be obviously problematic).

--
Tristan Wibberley

Any opinion expressed is mine (or else I'm playing devils advocate for
the sake of a good argument). My employer had nothing to do with this
communication.