derivation form collection? 
Author Message
 derivation form collection?

Why should I not derive directly form a collection?


Sat, 11 Oct 2003 20:03:59 GMT  
 derivation form collection?


Quote:
> Why should I not derive directly form a collection?

Because they don't have virtual destructors, and because they were not
designed to be derived from.

NeilB



Sat, 11 Oct 2003 20:53:36 GMT  
 derivation form collection?
    The problem is if you did something like:

    class A : public vector<int>
    {//// whatever
    };

    vector<int>* pVec = new A;
    /// whatever
    delete pVec;

    where you delete'd a new'd derived class through a pointer to the base
class.

    However, since you are NEVER going to do that.... Deriving from the
collection should be fine.

--
Truth,
James Curran
www.NJTheater.com     (Professional)
www.NovelTheory.com  (Personal)
www.BrandsForLess.Com (Day Job)


Quote:
> Why should I not derive directly form a collection?



Sun, 12 Oct 2003 02:32:17 GMT  
 derivation form collection?
Any idea why they were not designed for derivation? Just an oversight, or
other specific reason?

--
Jeff Flinn
Logic Systems, Inc.

Quote:



>> Why should I not derive directly form a collection?

>Because they don't have virtual destructors, and because they were not
>designed to be derived from.

>NeilB



Sun, 12 Oct 2003 20:54:15 GMT  
 derivation form collection?

Quote:

> Any idea why they were not designed for derivation? Just an oversight, or
> other specific reason?

It rarely makes sense to derive from a container: the interface usually
isn't appropriate for an application-specific class. Containers are
implementation details, and generally belong inside classes, with the
class providing a more suitable interface.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)



Sun, 12 Oct 2003 21:58:41 GMT  
 derivation form collection?

Quote:
> Any idea why they were not designed for derivation? Just an oversight, or
> other specific reason?

I wouldn't presume to assign motives to Stepanov et al, but I doubt it was
oversight! You might want to ask this question in comp.lang.c++.moderated,
where you will probably get a more considered response than you will here.

NeilB



Sun, 12 Oct 2003 21:19:33 GMT  
 derivation form collection?

and what is the problem with that?


Quote:
>     The problem is if you did something like:

>     class A : public vector<int>
>     {//// whatever
>     };

>     vector<int>* pVec = new A;
>     /// whatever
>     delete pVec;

>     where you delete'd a new'd derived class through a pointer to the base
> class.

>     However, since you are NEVER going to do that.... Deriving from the
> collection should be fine.

> --
> Truth,
> James Curran
> www.NJTheater.com     (Professional)
> www.NovelTheory.com  (Personal)
> www.BrandsForLess.Com (Day Job)



> > Why should I not derive directly form a collection?



Mon, 13 Oct 2003 18:31:22 GMT  
 derivation form collection?

Quote:

> and what is the problem with that?

The destructor of A is never called...

Quote:



> >     The problem is if you did something like:

> >     class A : public vector<int>
> >     {//// whatever
> >     };

> >     vector<int>* pVec = new A;
> >     /// whatever
> >     delete pVec;

> >     where you delete'd a new'd derived class through a pointer to the base
> > class.

> >     However, since you are NEVER going to do that.... Deriving from the
> > collection should be fine.

Markus


Mon, 13 Oct 2003 19:51:51 GMT  
 derivation form collection?

Quote:




> > >     The problem is if you did something like:

> > >     class A : public vector<int>
> > >     {//// whatever
> > >     };

> > >     vector<int>* pVec = new A;
> > >     /// whatever
> > >     delete pVec;

> > >     where you delete'd a new'd derived class through a pointer to the base
> > > class.

> > >     However, since you are NEVER going to do that.... Deriving from the
> > > collection should be fine.

> > and what is the problem with that?

> The destructor of A is never called...

The C++ language definition does not define the behavior of that code.
Anything it does is implementation-specific.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)



Mon, 13 Oct 2003 20:55:44 GMT  
 derivation form collection?

Quote:

>The C++ language definition does not define the behavior of that code.
>Anything it does is implementation-specific.

That is true.  And, in principal, anything at all could happen.  Your system
could start on fire, for example, and technically be compliant.  Or you
could get something more difficult to diagnose, like a seemingly random
memory corruption that was very hard to associated with the specific source
of the problem. You might not get a resource leak at all.

But the usual case is the destructor of the static type of the pointer will
be called, rather than the dynamic type of the object actually pointed at.
And this usually means a resource leak.

In any case, it is a thing to make strong efforts to avoid.  If a base class
has not got a virtual dtor, you better be extremely careful that there is
never a pointer to the base used to delete a derived object.  To do this,
never derive from a base class with a non-virtual dtor. And if you must,
then don't use a base pointer to point to a derived class. And if you must
do *that* then don't delete the object through the base pointer. Because
that is altogether likely to explode in some difficult to diagnose fashion.
Dan Evens



Tue, 14 Oct 2003 01:54:52 GMT  
 derivation form collection?

Quote:
> To do this,  never derive from a base class with a non-virtual dtor.
> And if you must, then don't use a base pointer to point to a derived
class.
> And if you must do *that* then don't delete the object through the base

pointer.

    But the point I was trying to make is that the ONLY time you'd want to
do all three of those things (ie, the only time such derivation is a
problem), is when you'd be using base class polymorphically.   That is, in a
case where you've intentionally used a class which can't be derived from for
a class the MUST be derived from.

    In other words, the code was already broken before you tried to derive
the class.

To clarify the point, let's look at the code I posted before:

    class A : public vector<int>
    {    //// whatever
    };

    vector<int>* pVec = new A;
    /// whatever
    delete pVec;

Now, this code will have a problem with the missing virtual dtor, but beside
that, it's just plain dumb.  No one would write that.  They'd write:
    A* pVec = new A;
    /// whatever
    delete pVec;
which is completely safe.

Ok, now let's try a variation:  You want to have a collection of objects,
all derived from vector<int>, and use them polymorphically.  That can still
be done safely:

class SafeIntVec: public std::vector<int>
{
public:
    virtual ~SafeIntVec() = 0;

Quote:
};

class A :: public SafeIntVec
{...};

class B :: public SafeIntVec
{...};

SafeIntVec* psiv = GetANewDerivedObject();
// :
delete psiv;

Now, the only problem come in when you have code (that you CANNOT change, ie
you are working with a third party library) in the form:

vector<int>* piv = GetANewDerivedObject();
// :
delete piv;

But then, that is intrinsically an error.
--
Truth,
James Curran
www.NJTheater.com     (Professional)
www.NovelTheory.com  (Personal)
www.BrandsForLess.Com (Day Job)



Tue, 14 Oct 2003 07:03:58 GMT  
 derivation form collection?
[snip]
Quote:
>Now, this code will have a problem with the missing virtual dtor, but
beside
>that, it's just plain dumb.  No one would write that.  They'd write:

[snip]

I think you have a higher opinion of the lower limit of programming wisdom
than do I. :^) But then I've spent the last three years with my nose in
legacy fortran. I'm fully convinced that coders, even senior coders, are
fully capable of writing any damn thing the compiler will allow.

James, we've had this conversation before. I don't think we disagree, just
have a different emphasis.

Dan Evens



Tue, 14 Oct 2003 23:18:55 GMT  
 derivation form collection?


Quote:

>It rarely makes sense to derive from a container: the interface usually
>isn't appropriate for an application-specific class. Containers are
>implementation details, and generally belong inside classes, with the
>class providing a more suitable interface.

So, what is the correct way to augment a container? Lets say we want
one with reference and ownershipp semantics (i.e. one that stores
pointers and delete these when it goes out of scope). At the moment, I
must duplicate nearly everything from the normal containers and add a
destructor. Inheritance *would* help here.

And what for strings? I found it convenient to derive from MS's
CString and add all the functionality we need. With std::string I can
only define non member functions to augment its functionality.

------------------------------------------------
Martin Aupperle

(remove NoSpam_)
------------------------------------------------



Tue, 21 Oct 2003 06:04:21 GMT  
 derivation form collection?
OTOH, practically any flavo(u)r of "smart pointer" solves the problem
withOUT mucking around in the internals of a container OR needing to derive
from it.


Quote:


> >It rarely makes sense to derive from a container: the interface usually
> >isn't appropriate for an application-specific class. Containers are
> >implementation details, and generally belong inside classes, with the
> >class providing a more suitable interface.

> So, what is the correct way to augment a container? Lets say we want
> one with reference and ownershipp semantics (i.e. one that stores
> pointers and delete these when it goes out of scope). At the moment, I
> must duplicate nearly everything from the normal containers and add a
> destructor. Inheritance *would* help here.

> And what for strings? I found it convenient to derive from MS's
> CString and add all the functionality we need. With std::string I can
> only define non member functions to augment its functionality.

> ------------------------------------------------
> Martin Aupperle

> (remove NoSpam_)
> ------------------------------------------------



Tue, 21 Oct 2003 19:53:57 GMT  
 derivation form collection?

Quote:

>So, what is the correct way to augment a container? Lets say we want
>one with reference and ownershipp semantics (i.e. one that stores
>pointers and delete these when it goes out of scope). At the moment, I
>must duplicate nearly everything from the normal containers and add a
>destructor. Inheritance *would* help here.

As Victor pointed out, this particular situation is better solved by some
sort of smart pointer, or reference count, or handle or some such idiom.
There are several such, and which one you pick will depend on exactly what
it is you are trying to do. The cool thing about that is, once you have the
handle for, say, vectors, you've got it for deques, maps, and lists as well.

Quote:
>And what for strings? I found it convenient to derive from MS's
>CString and add all the functionality we need. With std::string I can
>only define non member functions to augment its functionality.

For this case, I prefer to add the extra functionality as static members of
a StringUtil class.  That collects the extra stuff up in an obvioius named
area, making it pretty obvious what is going on. And it means any part of
the prog that is not actually using the extra functions does not have to
know about them.  And I can add one without modifying any such parts of the
prog.

The (other) thing about deriving from std::string (or CString) is that you
have no promise about how the class is implemented. If you start mucking
with internals of this version's implementation, who is to say that the next
version is going to do it the same? This time it might be a null terminated
char array. Next time it might be a length count and a char array. The time
after that it might be who knows what?

So you wind up writing the extra functions as though you only have the
std::string interface to access the string part. In other words, you write
pretty much the same functions  you would have written in my StringUtil
class.

Dan Evens



Tue, 21 Oct 2003 22:48:52 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

1. A collection inside a collection inside a collection...

2. Forms Collection?

3. Form Collection in Design Time

4. Populating collection Items within the collection

5. collection inside of a collection

6. Collections of collections

7. Derivation of PL/I

8. Derivation of PL/I (was Usenet group for PL/M language)

9. Pragma word derivation??

10. Symbolic derivation with ANSI C?

 

 
Powered by phpBB® Forum Software