Re: Best way to append std::list to itself
On Jan 6, 9:52 pm, Ian Collins <ian-n...@hotmail.com> wrote:
On 01/ 7/11 10:37 AM, Jorgen Grahn wrote:
On Thu, 2011-01-06, Paavo Helde wrote:
Jorgen Grahn<grahn+n...@snipabacken.se> wrote in
news:slrniic2f6.t7d.grahn+nntp@frailea.sa.invalid:
Did *you* test it? How?
#include<list>
#include<iostream>
int main()
{
std::list<int> foo;
foo.push_back(1);
foo.push_back(2);
foo.push_back(3);
foo.insert(foo.end(), foo.begin(), foo.end());
for(std::list<int>::const_iterator i = foo.begin();
i!=foo.end(); ++i) {
std::cout<< *i<< '\n';
}
return 0;
}
In what way am I wrong? I see no infinite loop. On my system this
prints 1 2 3 1 2 3 and that's also what I'd expect.
On my system this ate up some gigabytes of memory, then the whole system
hung. Seems like nasal demons to me ;-)
What is your system? Mine is Linux and gcc, AMD64 and ppc.
Interesting. Compiled with gcc, the code terminates with the 'expected'
output. With Sun CC, it loops forever.
I'm not saying you are mistaken or that your system has a bug; I just
want to know exactly what rule that code is violating. I found the
up-thread arguments unconvincing. (In particular, as you found out,
the suggestion "test it" was not helpful.)
The problem is probably how foo.end() is calculated.
Or how it is used inside insert. I can imagine that some
implementations first create the list to be inserted, then
splice it in (which gives "123123"), others insert one element
at a time (which results in an infinite loop if the end iterator
actually points to a "virtual" element guaranteed to be at the
end---a frequent implementation).
An implementation is free to use either, since it can assume
that the second and third iterators are not iterators into foo
(because this is a precondition for insert).
Just curious: but what would you "expect" as the behavior if the
first iterator were foo.begin() + 1 (i.e. into the middle of the
list being inserted)?
--
James Kanze