|
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