Re: Shouldn't advance be defined for ostream_iterator?

[Matt Austern <austern at apple dot com>]

On Feb 3, 2004, at 7:29 AM, Neal D. Becker wrote:

> On Tuesday 03 February 2004 10:21 am, Jonathan Wakely wrote:
> > On Tue, Feb 03, 2004 at 10:07:09AM -0500, Neal D. Becker wrote:
> > > ostream_iterator has operator++ (nop), but no generic advance.  I 
> > > believe
> > > advance should be defined:
> > >
> > > namespace std {
> > >   template<class T, class charT, class traits, typename dist_t>
> > >   inline void advance (ostream_iterator<T,charT,traits>, dist_t) {}
> > > };
> >
> > std::advance() requires an InputIterator, whereas 
> > std::ostream_iterator
> > is a model of the OutputIterator concept, and the description from
> > http://www.sgi.com/tech/stl/OutputIterator.html says:
> >
> >   [3] Assignment through an Output Iterator x is expected to alternate
> >   with incrementing x, and there must be an assignment through x 
> > before
> >   x is ever incremented. Any other order of operations results in
> >   undefined behavior. That is: {*x = t; ++x; *x = t2; ++x} is
> >   acceptable, but {*x = t; ++x; ++x; *x = t2;} is not.
> >
> > In other words, std::advance(x, 2) is not acceptable.
>
> Thanks for the reply.  Yes, I understand your argument, but the 
> premise is
> that since ostream_iterator is a model of output_iterator, and since 
> the
> requirements for output_iterator are X, therefore...
>
> Problem is the premise.  It's true that ostream_iterator is considered 
> a model
> of output_iterator, but that is really too restrictive.  In fact, 
> isn't it
> true that defining operator+= and advance for ostream_iterator would be
> perfectly harmless?  Don't you agree that if operator++ is a nop, that
> logically operator+= should be also?
>
> I can demonstrate code where it would be useful.

You should suggest that to the standards committee, not to the
libstdc++ mailing list.  The standard does not include any
operator+= for std::ostream_iterator<>.  We've been moving away
from these sorts of extensions, and in my opinion that's the right
decision.  If we make extensions like this, it's too hard for users to
tell which parts of the library are standard and which parts are there
just because we thought they might be useful.

			--Matt

P.S.  The easiest way to make sure the standards committee sees
your suggestion is to post it to comp.std.c++.  I'm curious what your
example is where this would be useful!