Sequence container capacity after calling clear()

Discussion in 'C++' started by Leigh Johnston, Mar 23, 2013.

  1. 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


    --
    [ comp.std.c++ is moderated. To submit articles, try posting with your ]
    [ newsreader. If that fails, use mailto: ]
    [ --- Please see the FAQ before posting. --- ]
    [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
    Leigh Johnston, Mar 23, 2013
    #1
    1. Advertising

  2. Leigh Johnston

    Öö Tiib Guest

    On Saturday, 23 March 2013 23:30:02 UTC+2, Leigh Johnston wrote:
    > 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.
    Öö Tiib, Mar 24, 2013
    #2
    1. Advertising

  3. Leigh Johnston

    James Kanze Guest

    On Saturday, March 23, 2013 9:30:02 PM UTC, Leigh Johnston wrote:
    > 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.

    --
    James
    James Kanze, Mar 24, 2013
    #3
  4. On Mar 24, 11:30 am, Leigh Johnston <> wrote:
    > On 24/03/2013 15:04, James Kanze wrote:
    >
    > > On Saturday, March 23, 2013 9:30:02 PM UTC, Leigh Johnston wrote:
    > >> 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.

    >
    > As I said in my post it is unspecified what happens to a vector's
    > capacity when calling clear().
    >
    >
    >
    > > 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.

    >
    > 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, Mar 24, 2013
    #4
  5. On Mar 24, 1:08 pm, Leigh Johnston <> wrote:
    > On 24/03/2013 16:57, Howard Hinnant wrote:
    > > I feel your frustration.  Direct it towards QNX.  The committee has
    > > asked and answered this question.

    >
    > 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
    Howard Hinnant, Mar 24, 2013
    #5
  6. Leigh Johnston

    James Kanze Guest

    On Sunday, March 24, 2013 3:30:10 PM UTC, Leigh Johnston wrote:
    > On 24/03/2013 15:04, James Kanze wrote:
    >
    > > On Saturday, March 23, 2013 9:30:02 PM UTC, Leigh Johnston wrote:

    >
    > >> 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.

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

    >
    > > 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.

    >
    >
    >
    > QNX.
    >
    >
    >
    > >

    >
    > >> 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.

    >
    >
    >
    > I repeat: the behaviour was and is unspecified.
    >
    >
    >
    > /Leigh
    James Kanze, Mar 24, 2013
    #6
  7. Leigh Johnston

    James Kanze Guest

    On Sunday, March 24, 2013 3:30:10 PM UTC, Leigh Johnston wrote:
    > On 24/03/2013 15:04, James Kanze wrote:
    > > On Saturday, March 23, 2013 9:30:02 PM UTC, Leigh Johnston wrote:
    > >> 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.


    > 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.

    > > 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.


    > QNX.


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

    > >> 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.


    > 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
    James Kanze, Mar 24, 2013
    #7
  8. Leigh Johnston

    James Kanze Guest

    On Sunday, 24 March 2013 19:47:59 UTC, Leigh Johnston wrote:
    > On 24/03/2013 19:38, James Kanze wrote:


    > > On Sunday, March 24, 2013 3:30:10 PM UTC, Leigh Johnston wrote:
    > >> On 24/03/2013 15:04, James Kanze wrote:
    > >>> On Saturday, March 23, 2013 9:30:02 PM UTC, Leigh Johnston wrote:
    > >>>> 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.


    > >> 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.


    > 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.

    --
    James
    James Kanze, Mar 26, 2013
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alex Molochnikov
    Replies:
    0
    Views:
    439
    Alex Molochnikov
    Oct 5, 2003
  2. Timo Nentwig

    List.size() != List.capacity();

    Timo Nentwig, Apr 12, 2004, in forum: Java
    Replies:
    11
    Views:
    3,608
    Larry Coon
    Apr 13, 2004
  3. David

    Response.Clear() doesn't clear

    David, Jan 31, 2008, in forum: ASP .Net
    Replies:
    2
    Views:
    996
    Mark Fitzpatrick
    Jan 31, 2008
  4. puzzlecracker
    Replies:
    4
    Views:
    332
    Hendrik Schober
    Oct 14, 2008
  5. InvalidLastName

    Unrecognized element 'add' after <clear></clear>

    InvalidLastName, Feb 26, 2007, in forum: ASP .Net Web Services
    Replies:
    3
    Views:
    926
    Steven Cheng[MSFT]
    Mar 6, 2007
Loading...

Share This Page