[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"