Deriving from STL containers

Lint (rightly I believe) complains that deque's destructor is not
virtual. So will the following code cause any problems?

If I do not derive from Container does that stop problems?
Do I manually have to call deque's destructor from Containers to make
sure?


Adrian

#include <stdexcept>
#include <deque>

class SomeClass
{

};

typedef std::deque<SomeClass *list_t;
class Container : private list_t
{
public:
Container() {};
using list_t::pop_front;
using list_t::front;
using list_t::empty;
using list_t::size;
void clear()
{
for(const_iterator i=begin(); i!=end(); ++i)
{
delete (*i);
}
list_t::clear();
};
void push_back(SomeClass * const obj)
{
if(size()>10)
{
throw std::runtime_error("much to big");
}
list_t::push_back(obj);
};

~Container()
{
clear();
}
private:
Container(const Container &);
Container &operator=(const Container &);
};

int main(int argc, char *argv[])
{
Container container;

for(int i=0; i<9; ++i)
{
container.push_back(new SomeClass());
}

return 0;
}

re: Deriving from STL containers

Adrian wrote:No.
What problems?
Absolutely not.
It is possible that you're going to leak memory if you allow
pop_front without deleting the element.
If you don't use 'argc' and 'argv', don't declare them.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

re: Deriving from STL containers

Adrian wrote:actually, quite the opposite. If you *do* public-derive from Container,
some problem can start to happen, due to the destructor of the child not
being called (you should then declare virtual the destructor of
COntainer). as long as you derive private, I think, there is no problem
at all.

Regards,

Zeppe

re: Deriving from STL containers

On May 31, 10:32 am, Adrian <n...@bluedreamer.comwrote:[snips]

http://www.parashift.com/c++-faq-lit....html#faq-20.7
Socks

re: Deriving from STL containers

Adrian wrote:No. The danger with a non-virtual destructor is that if you use new to
create an object of the derived type and subsequently delete it through
a pointer to the base type you get undefined behavior. Since your code
doesn't do either of those, it's fine. If you used your Container type
differently it might not be.
Yes, certainly. If you don't have a derived type then you can't delete
an object of that type through a pointer to its base.
No. There are very few situations where it's apropriate to explicitly
call a base class's destructor. Don't mess with that. If you delete an
object of type Container through a pointer to its base the behavior is
undefined. Nothing more can be said.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

re: Deriving from STL containers

Pete Becker wrote:Whoops, sorry: that was a more subtle question than I thought. No,
deriving from Container doesn't affect the possible problem.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

re: Deriving from STL containers

On May 31, 8:32 am, Adrian <n...@bluedreamer.comwrote:

Thanks all.