🚀 go-pugleaf

Mumit Khan (khan@xraylith.wisc.edu) wrote:

[ ... ]

>  1. What are the various things that you have find to be error-prone?

My main concern is runtime checking. As iterators don't hold any information
about the respective container, it is impossible to check whether 
an iterator is dereferencable or whether two iterators point to the same 
container. 

Of course you can write wrappers which bind iterator and container together,
but this will result in rewriting quite a portion of STL, and again
several different and incompatible solutions will emerge, which is exactly
what a standard should prevent.

And there are other nasty traps. Recently I fell into this one:

class str
{
  public:
	str(const string &s): st(s), i(0)	{	}
	int	operator<(const str &x) const	{	return i < x.i; }
	// ...

  private:
	string		st;
	int			i;
};

main()
{
	typedef	set<string, less<str> > strset; // Oops, should be less<string>

	strset	a;

	a.insert(string("one"));
	a.insert(string("two"));
	// ...
}

This program compiles and runs well, but gives wrong results. Errors like
this (I suspect there are a lot more of them lurking around) are difficult 
to catch. Although STL is not to blame for it - it's a general problem with 
templates - I'd prefer an interface which prevents the user from providing
inconsistent parameters.

--
+----------------------------------+
|          Bernd Eggink            |
|    Rechenzentrum Uni Hamburg     |
| admin@rzaix13.rrz.uni-hamburg.de |
+----------------------------------+

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