🚀 go-pugleaf

In article <MATT.95Sep14103019@physics10.berkeley.edu>,
Bernd Eggink <admin@rzaix53.uni-hamburg.de> wrote:
>
>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. 

This is a sticky point, and just about *everybody* I've corresponded
with has brought up this point. I at one point had added some code to
some of the iterators in ObjectSpace STL<ToolKit> to throw an exception
when you dereference an invalid iterator, but I haven't had the
"opportunity" to use it yet (so the code isn't really even tested).
What I don't like about my hack, and that's what you mention as well,
is that I've had to couple the iterator and container and I rather like
the (current) decoupled view of the two.

I'll see if I can easily retrofit the changes to the free implementation
(either HP reference or libg++) and then I'll post it. It's pretty simple
minded, basically built like the Fallible<T> in "Scientific and Engr C++"
by Barton and Nackman. I can't remember exactly how much I had actually
completed, but believe I only implemented the checked iterators for the 
sequential containers (list<T>, vector<T> and deque<T>), not for the 
associative ones.

the easiest implementation of a checked-iterator is of course is that
for the vector<T> class ...

As for a test if two iterators point to the same iterators, the coupling
would provide that as well.

Has anybody implemented this in a clean way??

>
>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"));
>	// ...
>}
>


But what would you like the compiler/implementations to do in these
cases? This is of course a design feature that you can pass custom
comparator function. Now if the compilers supported the draft, then
at least your problem will go away;

    template <class Key, class Compare = less<Key> > class set; 

so you'd never have to write code like you have to now unless you *want*
to supply a custom comparator (eg., when the key is a pointer to some
object). Your problem is solved.

Of course, if C++ provided constraints checking (see the D&E for a
discussion on this), you could do much more ...

Complain to compiler vendors to catch up to the standard. But wait, there
is no C++ standard. Aaargghhhh!

regards
mumit -- khan@xraylith.wisc.edu
http://www.xraylith.wisc.edu/~khan/

Cc: comp.std.c++, Bernd Eggink <admin@rzaix53.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. ]