Boost logo

Boost :

From: Victor A. Wagner Jr. (vawjr_at_[hidden])
Date: 2005-10-26 21:55:03


[deleted]

> >>
> >> are you suggesting that if it were class people: public
> >> std::vector<person> {.....}; as above the same would be true?
> >> not "in practice", "in theory".
> >
> > Absolutely. See 5.3.5/1 of the standard where this is explicitly called
> > out
> > as undefined behaviour.

5.3.5/1 looks like this in my copy of the standard
ISO/IEC
14882
Second edition
2003-10-15

5.3.5 Delete [expr.delete]
1 The delete-expression operator destroys a most derived object (1.8)
or array created by a new-expression.
delete-expression:
::opt delete cast-expression
::opt delete [ ] cast-expression
The first alternative is for non-array objects, and the second is for
arrays. The operand shall have a pointer
type, or a class type having a single conversion function (12.3.2) to
a pointer type. The result has type
void.

perhaps some other paragraph? this doesn't address anything about
derived objects.

>Yes, it you are trying to delete pointers to 'people' through base class you
>do need virtual destructor. But:
>
>1. In general in bad idea to inherit from STL container.

yet to be demonstrated, though asserted often

> Most probably you
>need a different relatationship (hint: containment)
>2. If you insist on inheritance you still in most cases wouldn't need
>virtual destructor: don't delete through pointers on vector. To reinforce
>this you could employ either private inheritance or protected destructor in
>wrapper around vector.
>
>In any case this is not a type of idiom anyone need to promote.

I disagree and will recapitulate the conversation thread with all
"changes" included so as to avoid confusion.

struct person {
   string first_name;
   string last_name;
};

person is a type and represents a concrete type. These can be new'd
and delete'd at whim, put in STL containers, whatever. Just your
almost ordinary C++ struct (not POD because of the non-trivial
destructor needed for the strings).

typedef std::vector<person> vecperson;

Another concrete type, newable. deleteable, and containable with no
special considerations.

struct choir
{
     vecperson SATB;
     ///some methods that play with SATB, NO additional data
     ///the only reason the destructor for THIS class is special is
because of the need to destruct SATB
     /// sizeof(vecperson) == sizeof(choir)
};

yet another concrete class, still nothing special, newable,
deletable, containable.

now for the final step;

struct people: vecperson
{
      ///some methods only, no data
      ///nontrivial constructor as choir, but we still have
      /// sizeof(vecperson) == sizeof(people)
};

I submit that people is a concrete type, with no restrictions on
newing deleting, or containing.
which means that

people* p = new people;
delete p;

is legal, well formed, and the behavior is defined.

NOW if the question everyone else answered is can you do this?

vecperson* pv = new people;
delete pv;

I _suspect_ that it will work just fine, but I'm not interested in
that problem, nor was there any indication in the OP that it was a requirement.

Victor A. Wagner Jr. http://rudbek.com
The five most dangerous words in the English language:
               "There oughta be a law"


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk