From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-09-28 12:26:32
> > 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
What means singular in this context? I do not see any problems with
Here is actual line which causes problems:
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk