This is the mail archive of the
libstdc++@sourceware.cygnus.com
mailing list for the libstdc++ project.
string issues [was problems with vector::iterator: 1]
- To: Philip Martin <pm at corris dot dircon dot co dot uk>
- Subject: string issues [was problems with vector::iterator: 1]
- From: Benjamin Kosnik <bkoz at cygnus dot com>
- Date: Thu, 18 Nov 1999 18:15:10 -0800 (PST)
- cc: libstdc++ at sourceware dot cygnus dot com
Ok y'all. I belive this is the last outstanding piece of backlog . . .
sorry 'bout the week wait. Anyway.
On the "do the right thing" fix for the ctors:
Please, somebody, anybody. We need a fix for this. (See the
21_string/ctor_copy_dtor.cc failure for more info). It should be a matter
of apply the vector fix to the string class. . . (i know this is not an
issue, but i'm hoping. . .)
On the const_isterator vs iterator:
I looked a bit more into this. I dimly remembered Philip going through
contortions to get the current const_iterator/iterator behavior correct.
And, I understand Scott's comment that this is not in the standard.
However.
This is an active, open issue for the library group:
179. Comparison of const_iterators to iterators doesn't work
It looks like it is the intention of the library committee to have stuff
like:
bool check_equal(std::deque<int>::iterator i,
std::deque<int>::const_iterator ci)
{
return i == ci;
}
work. Thus, it appears as if the testcases are correct, and should not
change. Libstdc++-v3 appears ahead of the curve on this one. So Scott, it
looks like your initial changes are not going to go
in. Your original bug (using std::rel_ops invoking misery) still remains,
tho. . .
On algo specializations via type-traits:
They're in. As for testing . . . dunno. I suppose if it makes a big speed
difference, and you looped it, then if we had a way of testing executable
speed, we'd have a rough guess.
-benjamin