Q:

Why the default constructed iterator can be used for the one-pass-end landmark?

int main() {
  boost::regex reg("(\\d+),?");
  std::string s="1,1,2,3,5,8,13,21";

  boost::sregex_iterator it(s.begin(),s.end(),reg);
  boost::sregex_iterator end;

  regex_callback c;
  int sum=for_each(it,end,c).sum();
}

As you can see, the past-the-end iterator passed to for_each is simply
  a default-constructed instance of regex_iterator.

Question> Since the end is NOT associated with any container, how does the std::for_each can use it as the ONE-PASS-END landmark of the container?
Thank you

A:

An important thing to remark is that this is not a general behavior.
In the standard, default constructed iterators act as “end”
iterators for iostream iterators, but not for iterators into a
container.  Usually, this idiom is used for input iterators, or other
cases where it is impossible to know the end of the sequence before
actually reading it.  The authors of boost::regex decided to follow 
this convention for boost::sregex_iterator; there was certainly no
requirement for them to do so.  But the fact that while it is a forward
iterator, it is generally impossible to know where the end is until you
try to advance to it, so the use seems sort of reasonable.
In the case of input iterators, the definition of “equals”
is rather loose, and about all that is required is that iterators
defined as “end” compare unequal to iterators which aren't
defined as “end”; a simple myIsAtEnd flag as member, and
bool
IteratorType::operator==( IteratorType const& other ) const
{
    return myIsAtEnd != other.myIsAtEnd;
}

or
bool
IteratorType::operator==( IteratorType const& other ) const
{
    return myIsAtEnd && other.myIsAtEnd;
}

is probably sufficient.  Since boost::sregex_iterator is a forward
iterator, and not simply an input iterator, the constraints are somewhat
more rigorous, but can easily be made to subsume the above, e.g. with
something like the following:
bool
boost::sregex_iterator::operator==(
    boost::sregex_iterator const& other )
{
    return myIsAtEnd
        ?  other.myIsAtEnd
        :  (!other.myIsAtEnd
            && myMatchPosition == other.myMatchPosition);
}

The default constructor simply setts myIsAtEnd to true.  (The other
constructor you use will start by trying to find the first match, and
will systematically set myIsAtEnd to whether it finds a match or not.)
It's probably worth pointing out that Boost often does this with
iterators.  The standard iterator concept is more or less broken (since
it requires two objects, rather than one), and this is a more or less
standard idiom for working around it.  You'll find it widely used in
boost::iterator as well, for things like filtering iterators.

