[boost] Re: Boost.Test token_iterator_test failure

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
> 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,