next »

[Evan Balster]

Code:

for (Entries::iterator i = entries.begin, e = entries.end(); i != e; ++i)
{
    //Stuff
}

Am I being too anal?

Discuss.

[BorisTheBrave]

I have a co-worker that talked me into doing this, so yes, I do. Not sure whether it really does much, but I did a bit of basic research and most compilers are not capable of optimizing (via loop-invariant hoisting) the more naïve approach into the same code as this.

I like to write:

Code:

typedef Entries::iterator Iterator;
for (Iterator i = entries.begin(), e = entries.end(); i != e; ++i)
{
    //Stuff
}

So that I can pretend I have something like C++0x's auto.

[Klaim]

Personally I don't pretend :


for( auto it= v.begin(); it != v.end(); ++it )
{
    doMyThing(*it);
}

Or better (but this one I can't with my current compiler):

for( Thin& thing : v )
{
   doMyThing(thing);
}

So until I got this feature in my main compiler, I prefer using lambda :

std::for_each( v.begin(), v.end(), [](Thing& thing)
{
    doMyThing(thing);
});

[Average Software]

Code:

for (Entries::iterator i = entries.begin, e = entries.end(); i != e; ++i)
{
    //Stuff
}

Am I being too anal?

Discuss.

One thing to note is that your approach might break if you alter this list mid-iteration, as this could invalidate your end iterator.

[mcc]

Code:

for (Entries::iterator i = entries.begin, e = entries.end(); i != e; ++i)
{
    //Stuff
}

Am I being too anal?

Discuss.

One thing to note is that your approach might break if you alter this list mid-iteration, as this could invalidate your end iterator.

Wouldn't that often invalidate "i" also, though.

[Average Software]

Code:

for (Entries::iterator i = entries.begin, e = entries.end(); i != e; ++i)
{
    //Stuff
}

Am I being too anal?

Discuss.

One thing to note is that your approach might break if you alter this list mid-iteration, as this could invalidate your end iterator.

Wouldn't that often invalidate "i" also, though.

The STL delete functions return the new i.

[BorisTheBrave]

The STL delete functions return the new i.

They usually return the next i though, meaning that the ++ would be wrong.

[Average Software]

The STL delete functions return the new i.

They usually return the next i though, meaning that the ++ would be wrong.

Which I why I decrement the i after deletion.  Should've mentioned that.

[Evan Balster]

Actually, some of my setup's erase functions don't return the next iterator, which leads to strangeness like this:

Code:

if (eraseThisEntry) erase(i++); else ++i;

I think it's maps or some such.  Might be standard.  Map iterators don't muck up in that case, at any rate.


Also, std::for_each is about as ugly as the nested function hack.  C++0x needs to come out soon.

Code:

struct {int operator()(int v)
{
   return 2 * v;
}} doubleIt;

[BorisTheBrave]

Which I why I decrement the i after deletion.  Should've mentioned that.

Code:

std::list l{1,2,3};
for(auto i = l.begin(); end = l.end(); i++)
{
  if(*i==1)
  {
    i = l.erase(i);
    i--;// oh bugger
  }
}

[Average Software]

Which I why I decrement the i after deletion.  Should've mentioned that.

Code:

std::list l{1,2,3};
for(auto i = l.begin(); end = l.end(); i++)
{
  if(*i==1)
  {
    i = l.erase(i);
    i--;// oh bugger
  }
}

I don't believe there's anything wrong with that.  It's the same location returned by rend().

[BorisTheBrave]

That's not how reverse iterators work. Look at this. Reverse iterators work on any bidirectional iterator. They do this by having a screwy dereference operator, but operating on the same range [begin,end], not by having a normal dereference operator, but operating on the range [begin-1, end-1].

This is because it is not legal to get an iterator to begin-1. Even if you don't deference it.

Name	Expression	Precondition
Predecrement	--i	i is dereferenceable or past-the-end. There exists a dereferenceable iterator j such that i == ++j

That said, it seems very unlikely an implementation depends on it.

[Average Software]

That's not how reverse iterators work. Look at this. Reverse iterators work on any bidirectional iterator. They do this by having a screwy dereference operator, but operating on the same range [begin,end], not by having a normal dereference operator, but operating on the range [begin-1, end-1].

This is because it is not legal to get an iterator to begin-1. Even if you don't deference it.

Name	Expression	Precondition
Predecrement	--i	i is dereferenceable or past-the-end. There exists a dereferenceable iterator j such that i == ++j

That said, it seems very unlikely an implementation depends on it.

Interesting.  It should be noted though that a lot of that SGI documentation is pre-standard and may be out of date.  I'll see if I can find a concrete reference to this in the standards document, and if this is in fact wrong, I'll stop doing it right away.

[Average Software]

That's not how reverse iterators work. Look at this. Reverse iterators work on any bidirectional iterator. They do this by having a screwy dereference operator, but operating on the same range [begin,end], not by having a normal dereference operator, but operating on the range [begin-1, end-1].

This is because it is not legal to get an iterator to begin-1. Even if you don't deference it.

Name	Expression	Precondition
Predecrement	--i	i is dereferenceable or past-the-end. There exists a dereferenceable iterator j such that i == ++j

That said, it seems very unlikely an implementation depends on it.

Interesting.  It should be noted though that a lot of that SGI documentation is pre-standard and may be out of date.  I'll see if I can find a concrete reference to this in the standards document, and if this is in fact wrong, I'll stop doing it right away.

Addendum:
The last draft of the C++0x standard that I downloaded confirms this.  I assume it's true for C++98 as well.  In either case, I'll certainly stop doing it, in preparation for the new standard if nothing else.

[LemonScented]

Code:

for(int i = 0; i < numberOfThings; ++i)
{
   // Stuff
}

To hell with your new-fangled iterators and STL garbage! REAL men do it with good old fashioned arrays, indexed with good old fashioned ints (signed ints, mind). Get off my lawn!