How do I use the iterator type when inheriting publicly from an STL container class?

Question

I am making a program in which I am inheriting publicly my Set class from a built-in STL container class set. I have to use the iterator type, while making some other specialized functions for my own Set class, as defined in the stl set class.

Now my question is: What would be the syntax to declare variables of iterator type inside my member functions? I have been trying:

  template<typename T>
  class Set : public set<T> {
         public:
         bool func()
         {
            iterator it,it2;
         }
   };

But the compiler is not recognizing iterator type. Kindly tell me the syntax to use the iterator type from the stl set class.

"iam inheriting publicly my Set class from a built-in STL container class 'set'"? Stop right there! Why are you doing this? — johnsyweb, Feb 05 '12 at 05:09
Iam making DFA program, hence set functionalities could be useful in it. I have no intention to use it polymorphically. — Zohaib, Feb 05 '12 at 05:11
@Zohaib: Then make `set` a class member of `Set`. [Prefer composition over inheritance](http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance). If you're not using it polymorphically, then there's no point in using inheritance. — In silico, Feb 05 '12 at 05:13
But i have to do it this way, since i have got a prototype of this program as my homework, and i have to implement it in the same way. — Zohaib, Feb 05 '12 at 05:16
Did a teacher seriously give a prototype of `template class Set : public set` in a homework exercise? Wow! — johnsyweb, Feb 05 '12 at 05:21
@Zohaib: I'm going to give you the benefit of the doubt and assume that this is in fact a constraint. Realize that inheriting from the standard containers is not recommended at all (see [this](http://stackoverflow.com/questions/2034916/is-it-okay-to-inherit-implementation-from-stl-containers-rather-than-delegate) and [this](http://stackoverflow.com/questions/6806173/why-should-not-i-subclass-inherit-standard-containers)). — In silico, Feb 05 '12 at 05:29

score 5 · Accepted Answer · edited May 23 '17 at 12:29

The compiler complains because it doesn't know that iterator is in fact a member of set<T>. set<T> is what's called a dependent type, because it depends on the type parameter T. In a nutshell, the compiler does not look inside dependent names when resolving types.

This FAQ entry is relevant to this question. Also, be sure to read through the answers to this Stack Overflow question. To fix it, use typename.

template<typename T> 
class Set : public set<T> { 
public: 
    bool func() 
    { 
        typename set<T>::iterator it;
        typename set<T>::iterator it2; 
    } 
};

But really, you should be using composition instead of inheritnace for this case, like this:

template<typename T>
class Set
{
public:
    bool func()
    {
        typename set<T>::iterator it;
        typename set<T>::iterator it2;
    }
private:
    std::set<T> set;
};

That fixed the problem, thnx alot. – Zohaib Feb 05 '12 at 05:24 — Zohaib, Feb 05 '12 at 05:24

score 0 · Answer 2 · answered Feb 05 '12 at 05:12

0

You should never ever ever ever ever inherit from an STL container class because the destructors of those classes are not virtual, and so every time you instantiate an instance of your derived class, you'll have a memory leak.

As In Silico suggested in one of his comments, give Set a member variable set instead of inheriting from it.

answered Feb 05 '12 at 05:12

Seth Carnegie

73,875
22
181
249

@Zohaib it doesn't matter, you'll still have a leak, don't ever do it. – Seth Carnegie Feb 05 '12 at 05:14
@Zohaib: if you want to reutilise Standard library container for building your own then you must in a `has-a` relationship a.k.a *composition* instead of *Inheritance*. – Alok Save Feb 05 '12 at 05:16
Ya u r right, i know But i have to do it in this way, since i have got a prototype of this program as my homework, and i have to implement it in the same way – Zohaib Feb 05 '12 at 05:19
1

IMHO, there are way too many "ever"s here. For instance, private unheritance can be just fine. Same goes for public inheritance if you don't *delete* it polymorphically. In fact, you're saying wrong things here. Just creating objects and using them normally is totally fine. I'd still recommend private inheritance, so access through the base class doesn't accidentally bypass your class' invariants. However, inheritance is a great tool even for STL containers, since you don't need to replicate all the member functions. Use what's fitting for the job. – Xeo Feb 05 '12 at 06:52
@Xeo It was my understanding that an STL container would have resources allocated in the constructor that need to be deallocated in the destructor, but the STL class' destructor would never be called because it is not `virtual`. Is that wrong? – Seth Carnegie Feb 05 '12 at 17:22
1

Yes, very much so! A child class destructor *always* calls the parent class destructor automatically (well, except if it throws an exception I think), no matter if it's virtual or not. It's the child class destructor that never gets called *if you delete the object through a base-class pointer* (which is also UB IIRC). – Xeo Feb 05 '12 at 18:05
@Xeo ahhhhhh then it is a gross misunderstanding on my part of what `virtual` means for destructors. Thanks very much, I'll delete this answer shortly. – Seth Carnegie Feb 05 '12 at 18:06

How do I use the iterator type when inheriting publicly from an STL container class?

2 Answers2