g++ typedef inheritance

[Søren Holstebroe]

Hi there,

I'm having a struggle with GNU g++ (3.3.5) and inheritance of typedefs in
STL containers.
I'm trying to port some old code I wrote with MS Visual C++ and it looks
like there is a discrepancy in the STL implementation or at least
interpretation of the standard (I trust g++ most on the latter).
To the case:

While this compiles fine:

-------------------
class B {
public:
typedef int foo;
};

class C : public B {
public:
void bar() {
foo a;
}
};
-------------

This doesn't work:
------------------
template <typename T, template <typename ELEM> class CONT = std::vector>
class pointainer : public CONT<T *>
{
public:
void foo() {
CONT<T *>::iterator it;
}
};
------------
tpltest.cc: In member function `void pointainer<T, CONT>::foo()':
tpltest.cc:9: error: parse error before `;' token
The vector iterator is defined in include/g++-v3/bits/stl_vector.h like
this:
typedef __gnu_cxx::__normal_iterator<pointer, vector_type> iterator;

Another thing is that I'm not sure that I'm on the right track when I
try to overwrite some functionalities of STL containers by inheritance.
I have been using a pointainer by Yonat Sharon in visual c++ for a long time
that was implemented in a similar way, but this pointainer doesn't compile
with g++.
The purpose of the pointainer is to automatically call the dtor of it's
objects when they are removed from the pointainer (or when the pointainer
is destructed). Yonat implemented that by overwriting many of the key
methods of the stl container. Since these methods are non-virtual, it would
give problems if the pointainer is used in a mother STL class context.

Currently I only see the solution of using composition instead of
inheritance which should clean any semantic problems, but will throw out my
free lunch. However I'm still curious why g++ wouldn't accept the stl
iterator usage.
---
Søren Holstebroe - http://www.holstebroe.dk

[Rolf Magnus]

Søren Holstebroe wrote:

Hi there,

I'm having a struggle with GNU g++ (3.3.5) and inheritance of typedefs in
STL containers.
I'm trying to port some old code I wrote with MS Visual C++ and it looks
like there is a discrepancy in the STL implementation or at least
interpretation of the standard (I trust g++ most on the latter).
To the case:

While this compiles fine:

-------------------
class B {
public:
typedef int foo;
};

class C : public B {
public:
void bar() {
foo a;
}
};
-------------

This doesn't work:
------------------
template <typename T, template <typename ELEM> class CONT = std::vector>
class pointainer : public CONT<T *>
{
public:
void foo() {
CONT<T *>::iterator it;
}
};
It isn't supposed to. Try:

typename CONT<T *>::iterator it;

------------
tpltest.cc: In member function `void pointainer<T, CONT>::foo()':
tpltest.cc:9: error: parse error before `;' token
The vector iterator is defined in include/g++-v3/bits/stl_vector.h like
this:
typedef __gnu_cxx::__normal_iterator<pointer, vector_type> iterator;

This is valid.
Another thing is that I'm not sure that I'm on the right track when I
try to overwrite some functionalities of STL containers by inheritance.
I have been using a pointainer by Yonat Sharon in visual c++ for a long
time that was implemented in a similar way, but this pointainer doesn't
compile with g++.
The purpose of the pointainer is to automatically call the dtor of it's
objects when they are removed from the pointainer (or when the pointainer
is destructed). Yonat implemented that by overwriting many of the key
methods of the stl container. Since these methods are non-virtual, it
would give problems if the pointainer is used in a mother STL class
context.

Currently I only see the solution of using composition instead of
inheritance which should clean any semantic problems, but will throw out
my free lunch.

What would you gain by that? You still couldn't use it in a context where
the base class is needed. If you just want to prevent anyone from trying
this, you could inherit privately and get the member functions you want to
keep into your derived class with using declarations.

[Søren Holstebroe]

Rolf Magnus wrote:

Søren Holstebroe wrote:

This doesn't work:
------------------
template <typename T, template <typename ELEM> class CONT = std::vector>
class pointainer : public CONT<T *>
{
public:
void foo() {
CONT<T *>::iterator it;
}
};

It isn't supposed to. Try:

typename CONT<T *>::iterator it;

This works. Thank you.

Currently I only see the solution of using composition instead of
inheritance which should clean any semantic problems, but will throw out
my free lunch.

What would you gain by that? You still couldn't use it in a context where
the base class is needed. If you just want to prevent anyone from trying
this, you could inherit privately and get the member functions you want to
keep into your derived class with using declarations.

My purpose was to semantically prevent base usage so private inheritance is
a solution. I just could get my using statements right and was in doubt
that this was the right track to follow anyhow. My overall purpose is to
make hide all the ugly memory management while still being able to use
containers of base class pointers with simple semantics. Ie. I want my
programs to be as readable, semantically simple and maintainable as my Java
programs.

The following naïve pointainer works with g++:

----------
#include <vector>
#include <iostream>

template <typename T, template <typename ELEM> class CONT = std::vector>
class pointainer : CONT<T *>
{
public:
using CONT<T *>::iterator;
using CONT<T *>::const_iterator;
using CONT<T *>::push_back;
using CONT<T *>::begin;
using CONT<T *>::end;

~pointainer() {
for (typename CONT<T *>::const_iterator it=begin();it!=end();it++) {
delete *it;
}
}

};

using namespace std;

class A {
public:
int v;
A(int _v) : v(_v) {cout << "A::ctor"<<endl;}
~A() {cout << "A::~dtor"<<endl;}
};

int main() {
pointainer<A> p;
p.push_back(new A(5));
p.push_back(new A(42));

for (pointainer<A>::const_iterator it=p.begin();it!=p.end();it++) {
cout << (*it)->v << endl;
}

return 0;
}
----------
Output is as expected:

A::ctor
A::ctor
5
42
A::~dtor
A::~dtor

--------------

Søren Holstebroe - http://www.holstebroe.dk