horstman@jupiter.SJSU.EDU (Cay Horstmann) wrote:
>Do you know of other

[apart from using the wrong iterator]

>STL traps and pitfalls that you'd like to be caught
>at runtime, rather than having a segmentation fault deep in the bowels of
>the template code? Thanks!

   0) [Supplying an iterator not reachble from another-already noted]
   1) Incrementing an iterator which is not incrementable.
   2) Dereferencing an iterator which is not dereferenceable.
   3) Violating a "no overlapping range" constraint (e.g. in "copy()")
   4) using an invalidated iterator

More subtle violations:

   6) providing an invalid comparison -- this one probably CAN'T be
      checked at run time. But it can cause, for example, "sort()"
      to go into an infinite loop, or mis-sort things.

   7) supplying an iterator of the wrong category [eg an input iterator
      where a forward iterator is required]

--
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

I am working on a presentation for C++ World (don't read this, Tara--I
know the deadline is next Monday), on how to make STL safer. I am
implementing something on the lines that Mumit Khan suggested, safer
iterators. Of course they are inefficient. My goal is to have a debug
version of the library with 100% compatible interface, but slower
performance. After you are done debugging, you can just go back to the
standard header files. (Even though my safer iterators have a lot more
data, like knowledge about their state and their owners, I am not making
it available--the goal is to stay 100% compatible with regular STL.)

Here are some things my debug library catches.

 list<int> a,b;
 list<int>::iterator p = find(a.begin(), b.end(), n);

(It will complain that a.begin() and b.end() have different owners. NB.
When Tom Keffer first showed me this one, I thought so what, NOBODY would
be stupid enough to make this error. It happened to me TWICE last week,
when I did cut and paste and was sloppy about renaming.)

 list<int>::iterator p = a.begin();
 b.erase(p);

(Try this in STL--it will erase the element from a, but reduce the length
of b!)


 vector<int> v;
 int* p = v.begin();

(The HP implementation of STL contains this bug many times.)

 vector<int>::iterator p;
 *p = 0;

(It will complain that p is not attached to a container.)

 vector<int> v;
 vector<int>::iterator p = v.begin();
 v.reserve(10000);
 *p = 0;

(It will complain that the array has been relocated. I could have moved p
along, but the spec says relocation invalidates iterators.)

Here is a borderline case.

 vector<int> v;
 v.reserve(10000);
 vector<int>::iterator p = v.begin();
 v.push_back(13);
 v.push_back(14);
 cout << *p;

The spec says that p is invalidated by the push_back. Technically, it
should be. First p pointed past the end of the empty v, then v got filled
and p now points to the first element, with a 13 into it. If you think of
an iterator as marking a cell with a definite contents, like in a list,
then indeed p should no longer be valid. But if you think of p as a
pointer, then so what--it still points to a perfectly good location.
What do you think?

Do you know of other STL traps and pitfalls that you'd like to be caught
at runtime, rather than having a segmentation fault deep in the bowels of
the template code? Thanks!

Cay
horstman@cs.sjsu.edu
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]