Hi,
Looks like subject test fails at runtime on following line:
std::list<char> l;
// here I populate l;
std::string s;
s.assign( l.begin(), l.end() ); // <---------- HERE
Funny things is that it start working if I change list to vector.
Is this some kind of gcc STL bug?
Should work fine - I take it you've simplified that code?
Yes, a bit.
This one http://tinyurl.com/3qdld (GCC 2.95) fails simply because std::string::clear() is missing in libstdc++-v2, you must use s.erase(s.begin(), s.end())
Actually I thought I fixed this one. s.erase() seems to be working.
For GCC 3.4.x the debug mode reports this: error: attempt to copy-construct an iterator from a singular iterator.
Are you sure you're passing l.end(), or is that a simplification?
I does simplified example a bit. I run test under gdb and found it fails in line similar to one above.
Loads of iterators in token_iterator_test.cpp are singular, so when passed to BOOST_CHECK_EQUAL_COLLECTIONS (which takes it's args by value) a singular iterator is copied - which is illegal e.g. test_custom_compare()
What means singular in this context? I do not see any problems with BOOST_CHECK_EQUAL_COLLECTIONS calls. Here is actual line which causes problems: typedef utf::range_token_iterator<std::list<char>::iterator> my_token_iterator; my_token_iterator tit( l.begin(), l.end() ); range_token_iterator implementation tries to build first token and use method assign for string with two iterators. Second iterator wouldn't be end but does it matter?
Also, why is test_wide() commented out for GCC (without STLPort) ? I thought the point of the \nnn octal escapes I worked out was that GCC won't accept the raw characters, but is happy with the escapes? Did that not work? Why should it work with STLPort, it's the compiler that rejects those chars, not the stdlib, isn't it? And it wasn't all versions of GCC that were affected, was it?
Just glitch from hurrying to fix it and making couple things together.
jon
Gennadiy,