std::list iterators and swapping

[Juha Nieminen]

Assume we have this:

std::list<Typel ist1(10, 1), list2(20, 2);
std::list<Type> ::iterator iter = list1.end();
list1.swap(list 2);

What happens here, according to the standard?

1) 'iter' still points to list1::end().
2) 'iter' now points to list2::end().
3) Undefined behavior.

[James Kanze]

On Jul 26, 1:23 pm, Juha Nieminen <nos...@thanks. invalidwrote:

James Kanze wrote:

The simplest solution (in my mind, anyway) uses inheritance:
you have a BaseNode with the pointers, and a DerivedNode
which contains the memory for the data.

Do you mean that you have a BaseNode object as member (as the
end node),

Yes.

but an iterator pointing to it would have a
DerivedNode type pointer pointing to this BaseNode type
object?

No. All pointers are always to the BaseNode; the element()
function of my iterator (which corresponds more or less to the
operator*() of a standard iterator) used a static_cast (actually
a C style cast, back then) to convert the pointer, e.g.:

return static_cast< DerivedNode* >( myPtr )->data ;

Is this even allowed?

Having a pointer to base which actually points to a derived is
certainly allowed:-). And templates (actually <generic.h>, back
then) guarantee the type, so the static_cast downcast is
guaranteed (unless you're at the end, of course).

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Pete Becker]

On 2008-07-26 07:17:15 -0400, Juha Nieminen <no****@thanks. invalidsaid:

Pete Becker wrote:

>When the allocators don't compare equal, you have to copy the elements.

That's what I thought, and that's why it sounded odd that the new
standard requires for iterators pointing to spliced elements to not to
be invalidated.

If there were an additional condition "unless the allocators in both
lists compare unequal", then it would make sense.

You snipped too much context. I was replying to the question of what
Dinkumware's implementation does, not to what the next revision of the
standard will require. Under the current standard the behavior when
allocators don't compare equal, for implementations that support this,
is implementation-defined.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)