🚀 go-pugleaf

In article <u9ka52iwn4.fsf@yorick.cygnus.com> jason@cygnus.com (Jason
Merrill) writes:

|> >>>>> 40763  <James> writes:

|> > One of the most useful idioms I've found with lists looks something
|> > like the following (with my list class):

|> > 	GB_DLListOf< T >    list ;
|> > 	for ( GB_DLListOf::Index i( list ) ; ! i.finished() ; ++ i )
|> > 	{
|> > 	    if ( someCondition( list[ i ] ) )
|> > 	        list.remove( i ) ;
|> > 	}

|> > To do the same with STL requires something like the following:

|> > 	list< T >           myList ;
|> > 	list< T >::iterator i( myList.begin() ) ;
|> > 	while ( i != myList.end() )
|> > 	{
|> > 	    list< T >::iterator      curr( i ++ ) ;
|> > 	    if ( someCondition( *curr ) )
|> > 	        myList.erase( curr ) ;
|> > 	}

|> > The incrementation *must* take place before the erase in order to work
|> > correctly.

|> This should work:

|> 	list< T >           myList ;
|> 	for ( list< T >::iterator i( myList.begin() ); i != myList.end(); )
|> 	{
|> 	    if ( someCondition( *i ) )
|> 	        myList.erase( i++ ) ;
|> 	}

|> Looks pretty similar, doesn't it?  Note that operator++ increments i
|> before it returns a value to be used in the erase.

This is the way I first wrote it, too.  So what happens when
someCondition is false.  (Presumably, it will be sometimes.
Otherwise, you would just write ``myList = list< T >() ;''.)

The correct body would become:

	if ( someCondition( *i ) )
	    myList.erase( i ++ ) ;
	else
	    ++ i ;

This looks like a maintenance nightmare to me.  Incrementing the
iterator in two separate places certainly makes it more difficult to
ensure that the iterator *does* get incremented (in all cases).  As
this is such an important part of the loop control structure (and the
guarantee that the loop terminates in finite time), I really want to
see it in the for statement.  Failing that, it should be in *one*
easily found place.

Note that my version using the STL really only contains one more
statement than my version using the fully safe iterators.  There is a
trade-off involved; my iterator *must* be a full class object, and its
construction involves registration with the container.  Even simple
indexation is more expensive, since it has to cope with the case where
the object under the iterator has been deleted.  This cost is present
even in programs which don't delete objects under the iterator.

In my opinion, the added cost is minimal, and well worth it.  But I
believe that the authors of the STL were aware of this alternative;
the current situation is the result of a concious choice, and not
simply a result of oversight or some such.

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone


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