end of std::list

[Glen Able]

Without further ado, here's some code:

std::list<int> things;

things.push_back(1);
things.push_back(2);
things.push_back(3);

std::list<int>::iterator it;
int test;

it = things.end();
test = *it; // obviously garbage

things.push_back(4);
test = *it; // garbage - but I was expecting '4'

I assumed that 'list' maintained an extra empty node at the end, which is
what gets returned by list.end(). Then I'd expect the 'push_back(4)' to
actually attach the value 4 to that node, which should then be returned in
the second 'test = *it' statement.

Anyone care to enlighten me?
thanks,
G.A.

 

[John Harrison]

Without further ado, here's some code:

std::list<int> things;

things.push_back(1);
things.push_back(2);
things.push_back(3);

std::list<int>::iterator it;
int test;

it = things.end();
test = *it; // obviously garbage

Actually undefined behaviour.

things.push_back(4);
test = *it; // garbage - but I was expecting '4'

I assumed that 'list' maintained an extra empty node at the end, which is
what gets returned by list.end(). Then I'd expect the 'push_back(4)' to
actually attach the value 4 to that node, which should then be returned in
the second 'test = *it' statement.

Anyone care to enlighten me?
thanks,
G.A.

This is covered by the 'invalidation of iterators' requirements that the STL
has. The requirements are different for different containers but for
std::list then only way to invalidate an iterator is to erase the element
that the iterator is pointing to. In all other cases iterators remain valid,
so for a std::list the return from end() will be the end of the list no
matter how many items are subsequently added or removed from the list.

john

 

[Nicolas Pavlidis]

Without further ado, here's some code:

std::list<int> things;

things.push_back(1);
things.push_back(2);
things.push_back(3);

std::list<int>::iterator it;
int test;

it = things.end();
test = *it; // obviously garbage

things.push_back(4);
test = *it; // garbage - but I was expecting '4'

AFAIK end() returns the data of an fixed node in the list(a member), and
so end() is always the same node.

Kind regards,
Nicolas

 

[Gernot Frisch]

Without further ado, here's some code:

std::list<int> things;

things.push_back(1);
things.push_back(2);
things.push_back(3);

std::list<int>::iterator it;
int test;

it = things.end();
test = *it; // obviously garbage

things.push_back(4);
test = *it; // garbage - but I was
expecting '4'

then use:
test = things.back(); and front(); they both give a reference to the
last/first element.

 

[Karl Heinz Buchegger]

Without further ado, here's some code:

std::list<int> things;

things.push_back(1);
things.push_back(2);
things.push_back(3);

std::list<int>::iterator it;
int test;

it = things.end();
test = *it; // obviously garbage

things.push_back(4);
test = *it; // garbage - but I was expecting '4'

I assumed that 'list' maintained an extra empty node at the end, which is
what gets returned by list.end(). Then I'd expect the 'push_back(4)' to
actually attach the value 4 to that node, which should then be returned in
the second 'test = *it' statement.

Where is it stated, that it has to be that way.

A list can also always use the very same node for marking the end of list
(if there is such a node at all, I don't think that dereferencing the end
iterator is an allowed operation. But I'm not sure about that)

If you push_back, a new node gets allocated and inserted just before that
end_of_list node.

 

[Glen Able]

Where is it stated, that it has to be that way.

A list can also always use the very same node for marking the end of list
(if there is such a node at all, I don't think that dereferencing the end
iterator is an allowed operation. But I'm not sure about that)

If you push_back, a new node gets allocated and inserted just before that
end_of_list node.

Bah. My actual application is trying to store references to positions in a
list (previously I was using a std::vector and indices). Problem is where
sometimes I need to add a reference to the place in the list where the next
element is going to be added, whenever that is. My naive interpretation of
'list iterators are never invalidated' lead me astray!

I guess I'll have to wrap the list in a class which has a collection of
references which need to be set to the next list element, whenever it gets
appended.

Thanks everyone.
G.A.