Re: shrink_to_fit and invalidation (C++0x)
Scott Meyers <NeverRead@aristeia.com> wrote:
On 11/6/2010 3:39 PM, Daniel T. wrote:
I found it surprising that shrink_to_fit was even applied to deque.
Does the new standard also add reserve and capacity to deque?
Because it seems to me that without at least capacity, shrink_to_fit
has no measurable effect on the container.
It allows the internal array of buffer pointers to be shrunk. Google
around for the document that led to this change in deque, and you'll
find a complete rationale. I don't have number or a link at hand
right now, sorry.
No problem...
http://msdn.microsoft.com/en-us/library/dd998399.aspx
This link comments that "There is no portable way to determine if
shrink_to_fit reduces the storage used by a deque Class." Note that
there is a portable way to determine if shrink_to_fit reduced the
storage used by string and vector. I consider this a flaw in the
standard.
Another interesting hit:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1755.html
This is a list of closed issues dated 2005 JAN 17. Item 101 talks about
the fact that there is no way to free storage for vector and deque. The
rationale informs us this is *not* a defect in the standard, the LWG
considered the issue and saw no need to add a shrink to fit function for
deque, because it has no reserve() member function. (It also points out
that they saw no need to add shrink_to_fit to vector because the
copy-swap idiom was quite adequate for the job.
http://www2.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html
By 2010 Oct 18 the issue seems to be reconsidered stating that the
copy-swap idiom is "somewhat obscure" and the shrink_to_fit() function
is proposed for string and vector (issue 755,) and later, in issue 850
the function is proposed for deque. Here is where the rational is.
Not surprisingly, the rational is that a deque could be holding on to
memory that the user code knows it no longer needs. However, variations
of this rational would also justify the addition of reserve() and
capacity() to deque.
Again, I'm left wondering at the inconsistency. The committee first says
that *because deque has no reserve()* it should not have a
shrink_to_fit(), yet it later decides to add shrink_to_fit() without
also adding reserve().
Either the committee should take shrink_to_fit out of deque's interface,
or it should also add reserve() and capacity() to deque.
Doesn't this make sense to you?