Re: [Boost-bugs] [Boost C++ Libraries] #4874: multi_array compile errors using Visual C++ 2010 in debug mode

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #4874: multi_array compile errors using Visual C++ 2010 in debug mode
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-02-13 20:18:55

#4874: multi_array compile errors using Visual C++ 2010 in debug mode
-------------------------------+--------------------------------------------
  Reporter:  chrislu           |       Owner:  garcia                                          
      Type:  Bugs              |      Status:  new                                             
 Milestone:  To Be Determined  |   Component:  multi_array                                     
   Version:  Boost 1.47.0      |    Severity:  Showstopper                                     
Resolution:                    |    Keywords:  multi_array, Visual Studio 2010, Visual C++ 2010
-------------------------------+--------------------------------------------

Comment (by anonymous):

 I have asked about this issue on comp.std.c++, and from what I have heard
 so far, my concerns about Visual C++'s current behavior and my potential
 "fix" for multi_array are justified.  The C++ standard is ambiguous around
 these issues.  The most relevant text that I can find 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.

 It appears that the intent of the standard suggests:

 1)  That the iterator category specifically BE an instance of one of the
 iterator tags, not simply  CONVERTIBLE TO one.  This makes my potential
 fix of providing an input_output_iterator_tag illegal.

 2)  On this basis, it appears that output_iterator_tag plays the role of a
 placeholder, and not a normative requirement.  Looking further at the
 standard, the classes that have output_iterator_tag as their category are
 classes like back_inserter and ostream_iterator, that do not satisfy the
 requirements of ANY OTHER iterator category, but since they are required
 by the above text to have an iterator tag, it simply must be
 output_iterator_tag, because otherwise they would violate the standard by
 not having a tag or having a non-applicable tag.  As such, it seems that
 output_iterator_tag just fills that space and is otherwise non-normative.

 By this interpretation, Visual C++'s debug-mode implementation is
 incorrect because checking for output_iterator_tag is not a requirement of
 an output iterator, it's just something that is true when an iterator is
 ONLY an output iterator and thus not qualified to have any other tag.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/4874#comment:20>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.