Output iterator

[Anders]

Hello there.

Can anyone tell me why the ++-operator is defined for ostream_iterato r ? I
can't see the difference between:

ostream_iterato r<int> test(cout);
test++ = 1;
test++ = 2;
test++ = 3;
test++ = 4;

and:

ostream_iterato r<int> test(cout);
test = 1;
test = 2;
test = 3;
test = 4;

//Anders

[Anders]

Re: Output iterator

And yes, I know that I should be using preincrement instead - it's faster:
---
test = 1;
++test = 2;
++test = 3;
++test = 4;
---


//Anders

[Howard Hinnant]

Re: Output iterator

In article <3eff61ac$0$325 46$edfadb0f@dre ad16.news.tele. dk>, Anders
<gregersen@adsl home.dk> wrote:

| Hello there.
|
| Can anyone tell me why the ++-operator is defined for ostream_iterato r ? I
| can't see the difference between:
|
| ostream_iterato r<int> test(cout);
| test++ = 1;
| test++ = 2;
| test++ = 3;
| test++ = 4;
|
| and:
|
| ostream_iterato r<int> test(cout);
| test = 1;
| test = 2;
| test = 3;
| test = 4;

It is so that generic code will work with ostream_iterato r. For
example:

template <class InputIterator, class OutputIterator>
OutputIterator
copy(InputItera tor first, InputIterator last, OutputIterator result)
{
for (; first != last; ++first, ++result)
*result = *first;
return result;
}

If you put an ostream_iterato r into copy as the OutputIterator, you
really do want it to compile and "do the right thing", which in this
case is nothing for operator++().

--
Howard Hinnant
Metrowerks

[Rolf Magnus]

Re: Output iterator

Howard Hinnant wrote:
[color=blue]
> In article <3eff61ac$0$325 46$edfadb0f@dre ad16.news.tele. dk>, Anders
> <gregersen@adsl home.dk> wrote:
>
> | Hello there.
> |
> | Can anyone tell me why the ++-operator is defined for
> | ostream_iterato r ? I can't see the difference between:
> |
> | ostream_iterato r<int> test(cout);
> | test++ = 1;
> | test++ = 2;
> | test++ = 3;
> | test++ = 4;
> |
> | and:
> |
> | ostream_iterato r<int> test(cout);
> | test = 1;
> | test = 2;
> | test = 3;
> | test = 4;
>
> It is so that generic code will work with ostream_iterato r. For
> example:
>
> template <class InputIterator, class OutputIterator>
> OutputIterator
> copy(InputItera tor first, InputIterator last, OutputIterator result)
> {
> for (; first != last; ++first, ++result)
> *result = *first;
> return result;
> }
>
> If you put an ostream_iterato r into copy as the OutputIterator, you
> really do want it to compile and "do the right thing", which in this
> case is nothing for operator++().[/color]

Actually, you must use operator++ to increment the iterator for each
read/write operation, since the implementation might choose to actually
rely on this.

[Rolf Magnus]

Re: Output iterator

Howard Hinnant wrote:
[color=blue]
> In article <bdnq3o$unr$01$ 1@news.t-online.com>, Rolf Magnus
> <ramagnus@t-online.de> wrote:
>
> | Howard Hinnant wrote:
> |
> | > If you put an ostream_iterato r into copy as the OutputIterator,
> | > you really do want it to compile and "do the right thing", which
> | > in this case is nothing for operator++().
> |
> | Actually, you must use operator++ to increment the iterator for each
> | read/write operation, since the implementation might choose to
> | actually rely on this.
>
> <nod> It might. But the C++ standard says in section 24.5.2.2 -
> ostream_iterato r operations, paragraph 3:
>
> | ostream_iterato r& operator++();
> | ostream_iterato r& operatot++(int) ;
> |
> | -3- Returns: *this
>
> (i.e. do nothing)[/color]

Does that mean the same as if it specifically said that the operator
does nothing?
[color=blue]
> I certainly would never write code that used ostream_iterato r in an
> unconventional manner that took advantage of this detail. And I'm not
> suggesting anybody should. But if you want to get picky,
> ostream_iterato r::operator++() is defined by the C++ standard to do
> nothing but return *this.[/color]

I didn't read in the standard, but in TC++PL3, which says:

"The ++ operation might trigger an actual output operation, or it might
have no effect. Different implementations will use different
implementation strategies. Consequently, for code to be portable, a ++
must occur between every two assignments to an ostream_iterato r."
[color=blue]
> And the main reason that ostream_iterato r
> has all of these "extra" operations that do nothing is so that it can
> be used seamlessly as any other iterator that supports the semantics
> required by output_iterator _tag (i.e. output, forward, bidirectional
> and random access iterators).[/color]

Ack.

[Howard Hinnant]

Re: Output iterator

In article <bdnuim$20g$01$ 1@news.t-online.com>, Rolf Magnus
<ramagnus@t-online.de> wrote:

| Howard Hinnant wrote:
|
| > <nod> It might. But the C++ standard says in section 24.5.2.2 -
| > ostream_iterato r operations, paragraph 3:
| >
| > | ostream_iterato r& operator++();
| > | ostream_iterato r& operatot++(int) ;
| > |
| > | -3- Returns: *this
| >
| > (i.e. do nothing)
|
| Does that mean the same as if it specifically said that the operator
| does nothing?

Hmm... no, I think you're right. It could have other effects, though
I'm having trouble coming up with a quick realistic example. Maybe
some kind of debugging info?

| > I certainly would never write code that used ostream_iterato r in an
| > unconventional manner that took advantage of this detail. And I'm not
| > suggesting anybody should. But if you want to get picky,
| > ostream_iterato r::operator++() is defined by the C++ standard to do
| > nothing but return *this.
|
| I didn't read in the standard, but in TC++PL3, which says:
|
| "The ++ operation might trigger an actual output operation, or it might
| have no effect. Different implementations will use different
| implementation strategies. Consequently, for code to be portable, a ++
| must occur between every two assignments to an ostream_iterato r."

Well, the standard explicitly says that the output will occur under
op=(const T&) operator:

| ostream_iterato r& operator=(const T& value );
|
| -1- Effects:
| *out_stream << value;
| if(delim != 0) * out_stream << delim;
| return (*this);

So I don't see how the op++ could also trigger output without really
messing things up.

| Ack.

Bill? Bill The Cat? Is that you?!! We've missed you soooo much! :-)

--
Howard Hinnant
Metrowerks