Boost C++ Libraries: Ticket #3999: multi_pass cannot deal with all input iterators

owner changed

Joel de Guzman — Thu, 11 Mar 2010 22:47:34 GMT

owner changed from Joel de Guzman to Hartmut Kaiser

status changed; resolution set

Hartmut Kaiser — Fri, 12 Mar 2010 02:18:25 GMT

status new → closed
resolution → fixed

(In [60496]) Spirit: fixed #3999:

anonymous — Fri, 12 Mar 2010 02:24:52 GMT

The commit mention above fixes the return value issue. Thanks for pointing this out!

The problem with Microsofts istreambuf_iterator has already been discussed on Spirit's mailing list. So I recently added a new input policy: buffering_input_iterator which is buffering the last character it got from the underlying iterator, which allows to return a refernce from multi_pass' operator*() in this case as well. This new policy is now the default input policy when using make_multi_pass(). It's a bit less efficient than the input_iterator policy, but helps to overcome the problem you described.

Regards Hartmut

Dave Abrahams — Mon, 10 Jun 2013 06:02:10 GMT

I'm not sure this bug should be considered fixed. multi_pass claims to make any valid underlying input iterator into a forward iterator, does it not? Shouldn't it select the right policy automatically? I have the same problem with clang's istreambuf_iterator in C++11 mode.

status changed; resolution deleted

Dave Abrahams — Mon, 10 Jun 2013 06:18:02 GMT

status closed → reopened
resolution fixed

In fact, under Clang with C++11, this program fails to compile:

#include <utility>
#include <boost/spirit/home/support/multi_pass.hpp>
#include <iterator>
#include <boost/mpl/assert.hpp>
#include <boost/type_traits/is_reference.hpp>
#include <boost/type_traits/is_same.hpp>
typedef boost::spirit::multi_pass<
    std::istreambuf_iterator<char>,
    boost::spirit::iterator_policies::default_policy<
        boost::spirit::iterator_policies::first_owner
      , boost::spirit::iterator_policies::ref_counted
      , boost::spirit::iterator_policies::buffering_input_iterator
    >
> iterator;
BOOST_MPL_ASSERT((
    boost::is_same<
        std::iterator_traits<iterator>::iterator_category
      , std::forward_iterator_tag>
));
BOOST_MPL_ASSERT((
  boost::is_reference<std::iterator_traits<iterator>::reference>
));
int main() {}

Dave Abrahams — Mon, 10 Jun 2013 06:27:43 GMT

…and I think this simple patch fixes it. Hopefully someone can check my reasoning

buffering_input_iterator_policy.hpp

-              old
+              new
                 typename boost::detail::iterator_traits<T>::pointer
             pointer;
             typedef
                 typename boost::detail::iterator_traits<T>::reference
+                result_type&
             reference;
             typedef result_type value_type;

Hartmut Kaiser — Mon, 10 Jun 2013 12:46:08 GMT

Replying to dave:

…and I think this simple patch fixes it. Hopefully someone can check my reasoning

buffering_input_iterator_policy.hpp

old new

49 49 typename boost::detail::iterator_traits<T>::pointer

50 50 pointer;

51 51 typedef

52 ~~typename boost::detail::iterator_traits<T>::reference~~

52 result_type&

53 53 reference;

54 54 typedef result_type value_type;

55 55

Does this mean that in your case result_type& is something different from typename boost::detail::iterator_traits<T>::reference? That does not look right to me.

Dave Abrahams — Mon, 10 Jun 2013 15:39:36 GMT

See the C++11 specification for istreambuf_iterator<char>. Note that result_type is just an implementation detail for this particular policy.

Dave Abrahams — Thu, 11 Jul 2013 10:04:40 GMT

I know everyone's busy, but it disturbs me that my my claim here is given so little credence, and when I offer a standard reference to prove my point, it isn't followed up on. I am, after all, an authority on the iterator requirements and an author of the Boost Iterator Library.

Hartmut Kaiser — Thu, 11 Jul 2013 11:51:35 GMT

Replying to dave:

I know everyone's busy, but it disturbs me that my my claim here is given so little credence, and when I offer a standard reference to prove my point, it isn't followed up on. I am, after all, an authority on the iterator requirements and an author of the Boost Iterator Library.

Even if you're the authority, you'll have to cut me some slack while I'm travelling and on holidays. There are more important things than iterators after all.

Dave Abrahams — Thu, 11 Jul 2013 14:58:43 GMT

Fair enough; enjoy your break, Hartmut. BTW your BoostCon talk is inspiring :-)

status changed; resolution set

Hartmut Kaiser — Wed, 31 Jul 2013 15:23:14 GMT

status reopened → closed
resolution → fixed

(In [85178]) Spirit: fixed #3999: multi_pass cannot deal with all input iterators

Dave Abrahams — Fri, 09 Aug 2013 20:28:19 GMT

Thanks!