|
Boost : |
From: Martin Bonner (martin.bonner_at_[hidden])
Date: 2005-10-26 09:31:37
----Original Message----
From: Victor A. Wagner Jr. [mailto:vawjr_at_[hidden]]
Sent: 26 October 2005 15:16
To: boost_at_[hidden]; 'boost_at_[hidden]'
Subject: Re: [boost] Is there any interest in a library that provides
cont ainers with virtual destructors?
> At 02:51 2005-10-26, Martin Bonner wrote:
>> ----Original Message----
>> From: Victor A. Wagner Jr. [mailto:vawjr_at_[hidden]]
>> Sent: 26 October 2005 05:36
>> To: boost_at_[hidden]; boost_at_[hidden]
>> Subject: Re: [boost] Is there any interest in a library that provides
>> containers with virtual destructors?
>>
>>> At 10:04 2005-10-25, Andy Tompkins wrote:
>>>> I have read a few times that people sometimes wish that std::vector
>>>> (or other containers) had a virtual destructor. [snip]
>>>> This allows one to write something like:
>>>>
>>>> struct person {
>>>> string first_name;
>>>> string last_name;
>>>> };
>>>> class people : public virtual_vector<person>
>>>> {
>>>> public:
>>>> //extra methods
>>>> };
>>>>
>>>> Is this useful?
>>>
>>> unless I mis-read (or mis-understood...far more likely) a lot of
>>> books on how C++ works, I don't believe there is any reason for what
>>> _you've_ shown to need a virtual destructor.
>>
>> You have mis-read or mis-understood (or you need better books).
>> Consider: virtual_vector<person>* p = new people;
>
> I guees I wasn't clear.. I was suggesting that virtual_vector has no
> need for existence.
>
>> delete p;
>> That invokes undefined behaviour unless virtual_vector<person> has a
>> virtual destructor.
>
> 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.
-- Martin Bonner Martin.Bonner_at_[hidden] Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk