🚀 go-pugleaf

I was with Tom on his ~const proposal until he proposed the following
bogus application:

In article <NGO.91Feb19114531@tammy.harvard.edu>, ngo@tammy.harvard.edu (Tom Ngo) writes:
|>          * Iterator.  An iterator might be a pair of methods init()
|>            and next() designed to be used like this:
|>            
|>                const A obj;   // container class of some kind
|>                obj.init(); while( obj.next() ) { ... }
|>            
|>            Here, I would either make the methods init() and next()
|>            ~const, or I would make the data members that record the
|>            state of the iterator ~const.

This is wrong, wrong, wrong.  next() really has changed obj's internal
state, because it has changed the effect of calling next() on that
object.  That is, the state of the internal pointer really is visible
outside the class.  I would recommend against using this to justify
~const.  I would also recommend against this style of iterator.

I prefer having a separate iterator class in such cases, and replacing
the init() and next() actions with something like

	const Container obj;		// container class

	ContainerIter next(obj);	// next is an iterator for Containers
	InsideObject* p;
	while ((p = next++) != 0) p->doSomething();

I don't care as much about the syntax, but I recently went through
a large system and got rid of iterators like Tom describes and replaced
them with iterators like I describe.  Why?

Tom's type of iterator means there are large numbers of objects floating
around the system with magic internal pointers.  Users forget to do the
.init() call or don't do them consistently, so the system has bugs in
it that depend on the order of iterator calls by who knows who.  Also,
there are thousands of these wasteful pointers floating around.

If ~const is implemented, it should only be used to support things that
don't affect the externally visible behavior of the object, like cacheing.
Tom's other three applications are all essentially cacheing of some sort:
there's an internal buffer that speeds up the operation of the class, and
equivalent, slower all-const form could have been written.


--
Joe Buck
jbuck@galileo.berkeley.edu	 {uunet,ucbvax}!galileo.berkeley.edu!jbuck