Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.std.c++ > #417

when is output_iterator_tag required?

From Ronald Garcia <garcia@osl.iu.edu>
Newsgroups comp.std.c++
Subject when is output_iterator_tag required?
Date 2012-02-11 08:40 -0800
Organization http://groups.google.com
Message-ID <82ab3e44-4905-4df3-9dc6-0eebbfca1371@iu7g2000pbc.googlegroups.com> (permalink)

Show all headers | View raw


VC 2010 under debug mode fails to compile specializes std::copy() to
check iterator tags. If the source iterators have iterator_category
random_access_iterator_tag, then they use a special implementation and
so on.  The fall-back case
though requires that the iterator_category be output_iterator tag.  I
have an iterator that I would like to be the target of copy, but it is
neither bidirectional nor random_access, so its iterator_category is
input_iterator_tag.  As a result, VC 2010 fails to compile calls to
copy, though only when in debug mode.
The outstanding question I have is whether it is necessary or even
legal for an iterator to have an iterator_category that is somehow
both input_iterator_tag AND output_iterator tag simultaneously.

First I say *legal* because in my copy of a standard draft, (24.3.3)
says:
For every iterator of type Iterator,
iterator_traits<Iterator>::iterator_category shall be defined to be
the most specific category tag that describes the iterator’s behavior.

I'm unclear on whether that can be any tag other than the specific
ones listed. In particular, can I legally create a class that inherits
from both input_iterator_tag and output_iterator tag to merge them.

Second, I say *necessary* because while input_iterator_tag,
forward_iterator_tag, bidirectional_iterator_tag, and
random_access_iterator_tag  form an inheritance chain, none of them
inherit from output_iterator_tag.  Furthermore, const_iterators like
"const int *" are not OutputIterators but seem to still be
RandomAccessIterators:  at least they still have category
random_access_iterator_tag.  So in this case I'm not sure when (if
ever) it is necessary to have an iterator category that is convertible
to output_iterator_tag.
I can't find information in practice or theory.  For instance, the
Boost.Concept library doesn't ever even look at the iterator_category
when checking OutputIterator concept.   All uses of
output_iterator_tag I can find in the standard are things like
back_inserter and front_inserter, things that are not "really"
iterators, so to speak.

So my question is:  if I have an iterator that satisfies the
expression requirements of InputIterator and OutputIterator,is there
*any* wording in the C++ Standard that dictates what is legally the
proper thing to do with its iterator_category?  If so, where can I
find it?  If it should have input_iterator_tag, then there is a (quite
reasonable) bug in VC++ 2010's debug mode.  If it should have both,
then I have a fix for my particular situation.  If there is no clear
answer, then the standard is underspecified on this matter.

Thank you,
Ron Garcia


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Back to comp.std.c++ | Previous | NextNext in thread | Find similar


Thread

when is output_iterator_tag required? Ronald Garcia <garcia@osl.iu.edu> - 2012-02-11 08:40 -0800
  Re: when is output_iterator_tag required? Daniel Krügler<daniel.kruegler@googlemail.com> - 2012-02-12 08:08 -0800

csiph-web