Re: [boost] Re: Querying usefulness of a macro for inheriting from STLcontainers

From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-02-25 12:45:34

----- Original Message ----- 
From: "Daniel James" <daniel_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, February 25, 2005 11:16 AM
Subject: [boost] Re: Querying usefulness of a macro for inheriting from 
STLcontainers

> christopher diggins wrote: I think publicly inheriting from a class that 
> isn't designed for inheritance is a bad idea. There are type safety 
> problems, non-virtual destructors, slicing etc.

Hi Daniel thanks for the help and suggestions ( and Kevin and Jonathan as 
well),

I have heard here and there, inheriting from STL container is a "bad idea", 
but I don't specifically know all the reasons why. I am not an expert in 
this area (heck or any part of C++ for that matter). Isn't it only bad if 
someone tries to delete the object using a base class pointer? Could we not 
prevent that idiom by writing type-casts which force failure upon a pointer 
cast to the inherited type?

For instance:

public MyCustomContainer : container {
  operator container*() {
    throw exception("can not cast to container*");
  }
...
}

Doesn't this solve the virtual destructor problem?

Another approach perhaps would be to create inheritable versions of the STL 
containers which are thin wrappers which simply provide a virtual 
destructor. Would this not work as well?

However what are the other problems of type-safety, slicing(?), etc. to 
which you allude? I am unfamiliar with them and I am not sure how to go 
about researching the topic.

There is another option of course, which is to use the BIL for delegation. 
This however has a small overhead which may not be acceptable in some cases.

Christopher Diggins
Object Oriented Template Library (OOTL)
http://www.ootl.org