Explicit declaration

[John Smith]

Hello,

I'm trying to port some code from Windows to Mac OSX with gcc.

Assume we have a class list which works like this:

template<class T>
class List
{
protected:
vector <T> m_List;
public:
typedef typename vector<T>::iter ator iterator;
iterator begin() {return m_List.begin(); }
iterator end() {return m_List.end();}
}

Now I have a derived class which extends this one:

template<class T>
class ServerList
{
void Func();
}

template<class T>
void ServerList<T>:: Func()
{
// Here is the problematic part
iterator it;
vector<iterator > ItVector;
....
}
}

Gcc doesn't accept "iterator" whereas microsoft compiler does. I'm honestly
not sure which is correct or if it's "undefined behavior" in this case, but
what I want is the ServerList::ite rator (from List).
So I tried to fix it by manually explicitly declaring it like this:

typename ServerList<T>:: iterator it;
vector<ServerLi st<T>::iterator > ItVector;

Is this the correct way?

Thanks in advance.
-- John

[Victor Bazarov]

John Smith wrote:

I'm trying to port some code from Windows to Mac OSX with gcc.

Assume we have a class list which works like this:

template<class T>
class List
{
protected:
vector <T> m_List;
public:
typedef typename vector<T>::iter ator iterator;
iterator begin() {return m_List.begin(); }
iterator end() {return m_List.end();}
} ;

Now I have a derived class which extends this one:

template<class T>
class ServerList
{
void Func();
} ;

Didn't you just say you _derived_ a class? Shouldn't it then be

template<class T> class ServerList : public List<T>

???

template<class T>
void ServerList<T>:: Func()
{
// Here is the problematic part
iterator it;
vector<iterator > ItVector;
...
}
}

Gcc doesn't accept "iterator" whereas microsoft compiler does. I'm honestly
not sure which is correct or if it's "undefined behavior" in this case, but
what I want is the ServerList::ite rator (from List).
'iterator' is a dependent name in 'ServerList<T>' (provided it *is* in
fact derived from 'List<T>'). You have to explicitly bring it into the
'ServerList<T>' s scope or fully qualify it.
So I tried to fix it by manually explicitly declaring it like this:

typename ServerList<T>:: iterator it;
vector<ServerLi st<T>::iterator > ItVector;

Is this the correct way?

Seems fine.

A side note: do you really want such a misnomer as "List" that is actually
a "vector"? I am currently maintaining a program full of such misnomers
and it is a PITA.

V

[Gianni Mariani]

John Smith wrote:

Hello,

I'm trying to port some code from Windows to Mac OSX with gcc.

Assume we have a class list which works like this:

template<class T>
class List
{
protected:
vector <T> m_List;
public:
typedef typename vector<T>::iter ator iterator;
iterator begin() {return m_List.begin(); }
iterator end() {return m_List.end();}
} ; need semicolon

Now I have a derived class which extends this one:

template<class T> : public List<T>
// I suspect you meant to add this
class ServerList
{
void Func();
} ; // need simicolon

template<class T>
void ServerList<T>:: Func()
{
// Here is the problematic part
iterator it;
vector<iterator > ItVector;
...
}
}

Gcc doesn't accept "iterator" whereas microsoft compiler does. I'm honestly
not sure which is correct or if it's "undefined behavior" in this case, but
what I want is the ServerList::ite rator (from List).
So I tried to fix it by manually explicitly declaring it like this:

typename ServerList<T>:: iterator it;
vector<ServerLi st<T>::iterator > ItVector; vector<typename ServerList<T>:: iterator> ItVector;

Is this the correct way?

yes

There is a defect report DR224 that covers this and there is a
discussion initiated by Scott Meyers on comp.std.c++ a few days ago.

[John Smith]

> Didn't you just say you _derived_ a class? Shouldn't it then be

template<class T> class ServerList : public List<T>

???
Yes it should be. Sorry... I just wrote some simple pseudo code so I
wouldn't have to copy the real code which is a tad more complex to read.
A side note: do you really want such a misnomer as "List" that is actually
a "vector"? I am currently maintaining a program full of such misnomers
and it is a PITA.

No I don't want and I use better names already. Again this was just to
illustrate the problem.

Thanks for your answer.

-- John

[John Smith]

> > template<class T>

: public List<T>
// I suspect you meant to add this

class ServerList
{
void Func();
} ; // need simicolon

Correct and as I wrote in the other thread it wasn't more then just pseudo
code I wrote.
There is a defect report DR224 that covers this and there is a
discussion initiated by Scott Meyers on comp.std.c++ a few days ago.

So in short, are microsoft compilers not handling the implicit statement
correctly?

-- John

[Matthias]

John Smith wrote:

Hello,

I'm trying to port some code from Windows to Mac OSX with gcc.

Assume we have a class list which works like this:

template<class T>
class List
{
protected:
vector <T> m_List;
public:
typedef typename vector<T>::iter ator iterator;
iterator begin() {return m_List.begin(); }
iterator end() {return m_List.end();}
}

Now I have a derived class which extends this one:

template<class T>
class ServerList
{
void Func();
}

template<class T>
void ServerList<T>:: Func()
{
// Here is the problematic part
iterator it;
vector<iterator > ItVector;
...
}
}

Gcc doesn't accept "iterator" whereas microsoft compiler does. I'm honestly
not sure which is correct or if it's "undefined behavior" in this case, but
what I want is the ServerList::ite rator (from List).
So I tried to fix it by manually explicitly declaring it like this:

typename ServerList<T>:: iterator it;
vector<ServerLi st<T>::iterator > ItVector;

Is this the correct way?

Thanks in advance.
-- John

Just one remark (wasn't quite obvious from your incomplete code sample):
IIRC you're not supposed to extend STL containers by using public
inheritance. It's problematic, because they don't define virtual
destructors. This includes std::list.
But you could consider using private inheritance to model "is
implemented in terms of" semantics. Or containment.

--
Regards,
Matthias

[John Smith]

> Just one remark (wasn't quite obvious from your incomplete code sample):

IIRC you're not supposed to extend STL containers by using public
inheritance. It's problematic, because they don't define virtual
destructors. This includes std::list.
But you could consider using private inheritance to model "is
implemented in terms of" semantics. Or containment.

I didn't do that either but thanks for telling me to watch out in future.
In my code I use vector, list, map etc. from the base classes and just give
a public way to access them like:

MyClass::iterat or it;

for (it = MyObj.begin(); it != MyObj.end(); it++)
....

instead of:

list<blah>::ite rator;

for (it = MyObj.m_List.be gin(); it != MyObj.m_List.en d(); it++)
....

The first one looks a little easier to read.
-- John

[Gianni Mariani]

Matthias wrote:

John Smith wrote: ....
Just one remark (wasn't quite obvious from your incomplete code sample):
IIRC you're not supposed to extend STL containers by using public
inheritance. It's problematic, because they don't define virtual
destructors. This includes std::list.
Hogwash.

This whole idea that classes that don't not have a virtual destructor so
you can't inherit has been discussed here many times and I believe the
consesnus is that it's silly FUD.
But you could consider using private inheritance to model "is
implemented in terms of" semantics. Or containment.

[Matthias]

Gianni Mariani wrote:

This whole idea that classes that don't not have a virtual destructor so
you can't inherit has been discussed here many times and I believe the
consesnus is that it's silly FUD.

What an insightful answer. All books I have read that deal with C++ tell
another story. I am curious to hear yours.

--
Regards,
Matthias

[Victor Bazarov]

Matthias wrote:

Gianni Mariani wrote:

This whole idea that classes that don't not have a virtual destructor
so you can't inherit has been discussed here many times and I believe
the consesnus is that it's silly FUD.

What an insightful answer. All books I have read that deal with C++ tell
another story. I am curious to hear yours.

I don't think Gianni should repeat all the discussions and conclusions
that can be looked up in the newsgroup archives. Please use Google to
search for them.

Also, you apparently read all the wrong books. Get better ones.