🚀 go-pugleaf

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. ]