This is the mail archive of the libstdc++@sourceware.cygnus.com mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

string issues [was problems with vector::iterator: 1]



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]