Sequence container capacity after calling clear()

[Leigh Johnston]

Hi,

Can we please change the ISO C++ Standard so that explicitly states what
happens to a sequence container's capacity() after calling clear()?

Currently the behaviour is unspecified and I know of at least one
implementation that deallocates on vector<T>::clear().

If the behaviour remains unspecified then it is effectively impossible
to write portable code that uses clear() and you have to hope things
such as v.erase(v.begin(), v.end()) behave more consistently across
different implementations.

/Leigh

 

[Öö Tiib]

Can we please change the ISO C++ Standard so that explicitly states what
happens to a sequence container's capacity() after calling clear()?

Currently the behaviour is unspecified and I know of at least one
implementation that deallocates on vector<T>::clear().

OTOH both deque and vector have shrink_to_fit member.

If the behaviour remains unspecified then it is effectively impossible
to write portable code that uses clear() and you have to hope things
such as v.erase(v.begin(), v.end()) behave more consistently across
different implementations.

You are putting it too strongly, in most situations I do not care either
way. Given that we have both shrink_to_fit and reserve we can make it to
behave exatly same either way.

 

[James Kanze]

Can we please change the ISO C++ Standard so that explicitly states what
happens to a sequence container's capacity() after calling clear()?

Currently the behaviour is unspecified and I know of at least one
implementation that deallocates on vector<T>::clear().

Has the specification in C++11 changed? In C++03, such an
implimentation would be illegal.

Could you tell me which implementation you are talking about.
I've not verified recently, but neither g++ nor VC++ behaved
like this in the past.

If the behaviour remains unspecified then it is effectively
impossible to write portable code that uses clear() and you
have to hope things such as v.erase(v.begin(), v.end()) behave
more consistently across different implementations.

There is nothing that I can see (in C++03) which allows an
implementation to reduce the value of container.capacity() when
calling clear.

 

[Howard Hinnant]

As I said in my post it is unspecified what happens to a vector's
capacity when calling clear().




QNX.

This issue has been discussed by the LWG:

http://cplusplus.github.com/LWG/lwg-closed.html#1102

Note the [ Batavia (2009-05): ] comment in which the CEO of the vendor
that supplies QNX with its std::vector implementation believes the
complaint of the issue is already implied by the standard.

Note also the [ 2009-10 Santa Cruz: ] comment in which the LWG closes
the issue as NAD because the standard is already correct as written
(to agree with the [ Batavia (2009-05): ] comment.

Bottom line: It looks like QNX is using an older version of the
std::lib which has a bug and simply needs to be updated. All std::lib
implementations have bugs and active implementations are continually
updated with bug fixes.

I feel your frustration. Direct it towards QNX. The committee has
asked and answered this question.

 

[Howard Hinnant]

Unless I am missing something I don't see how the current wording in the
Standard implies no deallocation on calling clear().  IMO it is not NAD;
without specifying the behaviour it is the implementation vendor that
can claim NAD.

You always have this option:

http://cplusplus.github.com/LWG/lwg-active.html#submit_issue

 

[James Kanze]

As I said in my post it is unspecified what happens to a vector's

capacity when calling clear().











I repeat: the behaviour was and is unspecified.



/Leigh

 

[James Kanze]

As I said in my post it is unspecified what happens to a vector's
capacity when calling clear().

Not in C++03, at least. It may be overspecification, but
clear() is defined to be exactly the same a erase(begin(),
end()). And that doesn't allow reducing capacity.

QNX.

I'm not familiar with it, but if clear() changes the capacity,
I'd send in a bug report.

I repeat: the behaviour was and is unspecified.

You can repeat it as much as you like. It's your word against
the standard, and in such cases, the standard rules. A quick
check does seem to indicate that C++11 has changed the
definition of clear(). The new definition is fairly ambiguous,
but I still don't see where it authorizes the capacity to
change.

 

[James Kanze]

On 24/03/2013 19:38, James Kanze wrote:

Stop being obtuse; the new definition doesn't say that the capacity
can't change either.

The standard, as written, doesn't allow the capacity to change
(or at least, it doesn't allow it to be reduced). The
restriction is very indirect, and you have to work through
a number of different constraints and guarantees on different
functions, but the guarantee is there. (It was slightly clearer
in the older versions, where clear was specified in terms of
erase. It's rather obvious that erase can't reallocate in
general, and there's no reason to assume that erasing everything
is a special case.)

I want the Standard to be changed so that it
explicitly states the behaviour re capacity when calling clear().

I would agree with that. I don't like rules which require
imagining special cases, then working through the constraints in
5 or 10 apparently unrelated sections in order to deduce them.