Re: [Boost-bugs] [Boost C++ Libraries] #6373: transform_iterator not preserving bidirectionality of std::map iterator

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #6373: transform_iterator not preserving bidirectionality of std::map iterator
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-10-08 03:56:34


#6373: transform_iterator not preserving bidirectionality of std::map iterator
--------------------------------------+-------------------------------------
  Reporter: JonT <jon@…> | Owner: dave
      Type: Bugs | Status: new
 Milestone: To Be Determined | Component: iterator
   Version: Boost 1.49.0 | Severity: Problem
Resolution: | Keywords: transform_iterator bidirectional std::map
--------------------------------------+-------------------------------------

Comment (by jeffrey.hellrung):

 Actually there's a couple things going on here. At least for the
 referenced StackOverflow question, the poster is "lying" about the result
 of XFunc. The correct way to define XFunc is as

 {{{#!cpp
 template <typename Pt>
 struct XFunc
 {
     typedef typename Pt::first_type & result_type;

     result_type operator()(const Pt &p) { return p.first; }
 };
 }}}

 and then the example code works.

 However, more fundamentally, if your composition function does *not*
 return a genuine C++ reference (which was what was being told to
 transform_iterator prior to the above change), there's not a whole lot
 iterator_facade can do strictly within the constraints of the C++
 standard: ISO/IEC 14882:2003(E) 24.1.3 describes the requirements of
 Forward iterators (of which Bidirectional iterators are a refinement), and
 the relevant requirement in this case is that "*a" returns a genuine C++
 reference (not a proxy reference, not by-value). This is (IMHO) a
 deficiency in the STL categorization of iterators, hence the rationale for
 Boost's separate traversal and access tags.

 The immediate workaround is to override transform_iterator's deduction
 mechanism for the iterator_category typedef by explicitly providing it. A
 more long-term workaround is to drum up support within the C++ community
 for a change in the standard wording and/or support within the Boost
 community for a change in the behavior of iterator_facade to conform more
 to "common sense" than to the strict word of the standard.

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

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:10 UTC