std::list::end will return something from the std::list, it is inlined and in
GNU world it looks like this:

iterator
end()
{ return iterator(&this->_M_impl._M_node); }

and underneath, without looking to closely, the type iterator is basically a
wrapper over a pointer, so no big deal.

I still have not gotten to the difference yet: if the std::list object is passed by
pointer or reference, then the value looked up from std::list::end() is not
on the stack, where as

std::list::iterator i, end;

are on the stack. So in _theory_ what the poster said could avoid a cache miss.
Because of side effects, the compiler cannot cache the return value to std::list::end,
unless the contents of the for-loop contains no function calls (or all function calls
are inlined function and those themselves follow that rule and all do not
touch the std::list, but even then that is putting alot of faith in the optimizing compiler).
But even then, the memory location where the value of std::list::end is located will
be put into the cache anyways after the first call, so unless the contents do enough
jazz to push it out of the cache, then there won’t be a cache miss anyways.

For std::vector, the story is actually the same, internally the end of the container is stored,
not the size, so repeated calls to std::vector::end are the same story, so you _might_ get
a cache miss in doing it, with the same jazz as noted for std::list::end.

Lastly, the boost macro BOOST_FOR_EACH, uses saving the begin and end iterators as
well, so for such loop constructs it is bad luck to add/remove elements from the
container. Generally speaking, one usually cannot go wrong in emulating the behavior
of boost.

std::list::iterator it = l.begin();
const std::list::iterator end = l.end();
while (it != end) { /* whatever */ it++; }

I don’t do this much, but it is possible too:

void PrintSomeItems(std::list::iterator& it, const std::list::iterator& end)
{
while (it != end) { /* whatever */ it++; }
}

PrintSomeItems(it, end);

This function can be templated to accept a vector too for more awesomeness.

Long story short, they were EXACTLY the same when using optimization. Without optimization, there was a penalty for calling end() each time… it is not a O(1) but O(lg n) operation.

All-in-all, Evan I only have one issue with the blog… you need to post more often. As always, good stuff!