Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!apple!agate!pasteur!galileo.berkeley.edu!jbuck From: jbuck@galileo.berkeley.edu (Joe Buck) Newsgroups: comp.std.c++ Subject: Re: Responses to ~const 1.6: Experience? Message-ID: <11287@pasteur.Berkeley.EDU> Date: 20 Feb 91 02:15:07 GMT References: Sender: news@pasteur.Berkeley.EDU Reply-To: jbuck@galileo.berkeley.edu (Joe Buck) Distribution: comp Lines: 49 I was with Tom on his ~const proposal until he proposed the following bogus application: In article , 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