Donald Xie wrote:
>
> === Quote ===========================================
> 24.1 Iterator requirements
>
> 3 Forward iterators satisfy all the requirements of the input and output
> iterators and can be used whenever either kind is specified; ...
> === End of quote =======================================
>
> So a forward iterator should do whatever a output iterator can?

Yup, that's what it says. It's something of an overstatement, although
in a sense it's correct: the operations that you can perform on output
iterators are a proper subset of the operations that you can perform on
forward iterators. The problem is that in actual practice you make
different assumptions about whatever it is that the iterator is writing
to. Output iterators write to unbounded containers, forward iterators
write to fixed size containers.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete,

Don't mean to start a debate <grin>.  I understand what you said in your
original reply:

> No. The reason that forward_iterator_tag is not derived from
> output_iterator_tag is that an output iterator is conceptually
> unbounded: you write to it as long as you have data. A forward iterator
> is bounded: there is a fixed number of elements available to you.
>
> // Examples ignored ...
>
> You cannot plug in a forward iterator where an output iterator is
> expected. That's why forward_iterator_tag is not derived from
> output_iterator_tag.

but what puzzles me is that the CD2 says that


=== Quote ===========================================
24.1 Iterator requirements

3 Forward iterators satisfy all the requirements of the input and output
iterators and can be used whenever either kind is specified; ...
=== End of quote =======================================

So a forward iterator should do whatever a output iterator can?

Thanks again
Donald

Pete Becker wrote in message <35C357B6.15794F92@acm.org>...
>... The reasons that I
>presented were those that were discussed at the meeting at which the
>decision in question was made. If someone sees some fault in the logic
>and wishes to discuss it they should do so. As is, there's nothing more
>to say. There were good reasons for the decision, and there have not
>been any logical arguments presented to the contrary.
>
>--
>Pete Becker
>Dinkumware, Ltd.
>http://www.dinkumware.com







      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35A766EF.5E5D6E9E@acm.org>,
  Pete Becker <petebecker@acm.org> wrote:
> Valentin Bonnard wrote:
> >
> > Donald Xie <donald@iinet.net.au_RemoveThisWhenReply> writes:
> >
> > > Is there any reason why the STL forward_iterator_tag is derived from
> > > only the input_iterator_tag instead of both the input_iterator_tag and the
> > > output_iterator_tag?  All I can see is that iterator tags are conceptual
> > > and have no real use other than specifying the types of iterators so it
> > > doesn't matter how forward_iterator_tag is derived.  Can anyone offer a
> > > better explaination on this?
> >
> > No one cares. Yes, that's an explanation.
>
> But it's not the right one.
>
> >
> > The more detailed explanation is that it was forgoten the
> > first time and after no one wanted to do the work (ie to
> > add ", output_iterator_tag" in forward_iterator_tag definition.
>
> No. The reason that forward_iterator_tag is not derived from
> output_iterator_tag is that an output iterator is conceptually
> unbounded: you write to it as long as you have data. A forward iterator
> is bounded: there is a fixed number of elements available to you. For
> example:
>
> template<class In, class Out>
> Out copy(In begin, In end, Out target)
> {
> while(begin != end)
>  *target++ = *begin++;
> return target;
> }
>
> int main()
> {
> std::copy(std::istream_iterator<char>(std::cin),
>  std::istream_iterator<char)(),
>  std::ostream_iterator<char>(std::cout));
> return 0;
> }
>
> That works just fine, because a conceptually unbounded input source is
> being copied to a conceptually unbounded output sink. On the other hand,
>
> int main()
> {
> std::vector<char> v;
> v.push_front('a');
> v.push_front('b');
> std::copy(std::istream_iterator<char>(std::cin),
>  std::istream_iterator<char)(),
>  v.begin());
> return 0;
> }
>
> This one's trouble, because copy starts writing to invalid memory
> addresses after the first two characters have been copied.
>  You cannot plug in a forward iterator where an output iterator is
> expected. That's why forward_iterator_tag is not derived from
> output_iterator_tag.
>
Thanks and that certainly makes sense.  However, this question came up when I
read the C++ Standard Draft CD2 that states:

24.1 Iterator Requirement

Forward iterators satisfy all the requirements of the input and output
iterators and can be used whenever either kind is specified;

It seems to me that we _should_ be able to use a forward iterator in place for
an output iterator.  I haven't read the final paper yet so please excuse me if
this has been changed.

TIA
Don

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]