Re: std::vector: Surprising order of destruction!
In article <jqp1tv$ebq$1@usenet.stanford.edu>,
Seungbeom Kim <musiphil@bawi.org> wrote:
On 2012-06-06 17:02, Christopher Dearlove wrote:
On Jun 2, 1:53 pm, brang...@cix.compulink.co.uk (Dave Harris) wrote:
It seems to me leaving destruction order implementation defined, is
giving the implementation a freedom that it doesn't need, while taking
away a guarantee that users sometimes do need.
I don't see any sensible user needing that guarantee, even if it
weren't for all the examples that show problems.
A user sensible enough could start something with an array, and then
later decide to switch to a vector. If a complex program crashes just
after switching from an array to a vector, the user will have to spend
a good amount of time debugging it in frustration.
Being dependent on order of destruction within a container is rare. And
once you learn you cannot rely on the containers doing it, you deal with
it. If you really need it, you can always make your own destructor
enforce it.
(Indeed, lots of literature teach readers that they should avoid
raw arrays and substitute container classes wherever possible
because "arrays are evil", encouraging such switches.)
If we tighten the requirements on the destructor, what should the
following do:
v.clear()
v.erase(v.begin(), v.end())
Should other sequence containers also be changed? Arguably, people use
deques and lists for FIFOs, so they could use the guarantee too. (On
the other hand, you can still make a FIFO with push_front and pop_back.)
It's just how a problem buried in a complex real-world situation is
reduced to its essence and presented to others, as they'd better be.
Such a reduced form may of course seem unrealistic and artificial,
but it doesn't mean the problem is irrelevant.
My own feeling is that I wouldn't be opposed to this change, unless
library vendors have some compelling reason (such as efficiency) to keep
the status quo.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com>
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]