I am looking for opinions on the stability of the list<T>::erase()
method w.r.t. the ordering of the list elements that are not
removed.

In 23.2.2.4 the Standard states that list<T>::remove() and
list<T>::remove_if() are stable, but 23.2.2.3 makes no such
statement about list<T>::erase().

Comments?

MV


Martin Vuille      | Real-time and | Software & Firmware Contracting
JPMV Realtime Inc. |   embedded    | Turnkey Controls Development
Tel.:(613)823-0777 |   control     | System Integration
Fax.:(613)823-3034 |  specialist   | Product Development Consulting

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <997036096.487669@news.aei.ca>, Martin Vuille
<jpmv27@yahoo.com> writes
>
>I am looking for opinions on the stability of the list<T>::erase()
>method w.r.t. the ordering of the list elements that are not
>removed.
>
>In 23.2.2.4 the Standard states that list<T>::remove() and
>list<T>::remove_if() are stable, but 23.2.2.3 makes no such
>statement about list<T>::erase().
>
>Comments?

I do not think we need any such requirement. It is a QoI issue. Any
list<T>::erase() that did not preserve previous order would have to be
perverse because it is the nature of lists to remain stable. I think the
same applies to remove, and I suspect that the current wording is simply
that none of us could see any reason for changing the wording from that
used in algorithms (where it does matter).


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <gIodOdBKubb7Ew5N@ntlworld.com>, Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
>I do not think we need any such requirement. It is a QoI issue. Any
>list<T>::erase() that did not preserve previous order would have to be
>perverse because it is the nature of lists to remain stable.

I agree that there is no reason for erase to be unstable, and that is
what I have assumed.

But I would still prefer a stronger statement in the standard since
the only mention of stability in connection with the list container
seems to be the notes in certain of its member functions.

>                                                            I think the
>same applies to remove, and I suspect that the current wording is simply
>that none of us could see any reason for changing the wording from that
>used in algorithms (where it does matter).

I didn't understand what you meant here until you and Carlos pointed out
to me in c.l.c++.m that, contrary to my delusions, remove and remove_if
are also documented as being stable. Now it makes sense.

Thanks for your responses.

MV


Martin Vuille      | Real-time and | Software & Firmware Contracting
JPMV Realtime Inc. |   embedded    | Turnkey Controls Development
Tel.:(613)823-0777 |   control     | System Integration
Fax.:(613)823-3034 |  specialist   | Product Development Consulting

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]