This is the mail archive of the libstdc++@gcc.gnu.org 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]
Other format: [Raw text]

Re: unsafe STL patch


Hi,
> I solved my problem, indeed it was coming from pch. I have regenerated
> them now and it works fine, I will complete the patch.
wait...
> About the limitation to random access iterator. It has to be so to
> keep on detecting this kind of problem:
>
> using namespace std;
> list<int> l({1, 2, 3});
> vector<int> v;
>
> list<int>::iterator first(l.begin()), last(l.begin());
> ++first; ++first;
> ++last;
> v.insert(v.end(), first, last);
>
>    You see range iterator is badly defined because first is after
> last. This is something that cannot be detected by the check_range
> function because there is no < operator on bidirectional iterator. The
> problem will only appear when we will reach past the list end when
> incrementing first if first is still a _Safe_Iterator.
I see. Hey, when presenting your work, you should discuss these details
in the first place! ;)

Anyway, before going ahead with more details, I'd like to understand
more about the core idea: is it only in order to improve the
*performance* of debug mode? How much do you expect the performance to
improve? Are you **really** sure we don't loose any debug power (eg.,
please explain why operator* of base() is equivalent, just more
efficient, to operator* of _Safe_iterator)? Are the prospective changes
limited to such templatized members?

Paolo.


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