Subject: Re: [boost] [iterator] Help needed understanding output_iterator requirements
From: Jeffrey Hellrung (jhellrung_at_[hidden])
Date: 2010-03-15 11:12:30
Thomas Klimpel wrote:
> Dear iterator experts,
>
> Jesse Perla recently reported that boost::multi_array fails compilation for many basic tasks on MSVC 2010. I investigated the failures, because I had already investigated other failures on MSVC 2010 reported by Jesse Perla for boost::ublas. While I'm quite familiar with boost::ublas, I'm a complete novice with respect to boost::multi_array and boost::iterator.
>
> I could track the failures to a specific (intentional?) behavior of iterator_facade from Boost.Iterator (more specifically of facade_iterator_category.hpp):
>
> http://listarchives.boost.org/Archives/boost/2010/03/163039.php
>
>
> Thomas Klimpel wrote:
>> What effectively happens it that the iterator gets the category
>> "input_iterator", but std::copy wants to have an "output_iterator". I
>> think I understand why the iterator doesn't satisfies the requirement
>> of a "forward_iterator", but it's unclear to me why it didn't qualify
>> as an "output_iterator". There is an "input_output_iterator_tag" in
>> "boost/iterator/detail/facade_iterator_category.hpp", so it would have
>> been possible for the iterator to be both "input_iterator" and
>> "output_iterator". However, it seems to me that
>> "input_output_iterator_tag" is never used in the Boost.Iterator
>> library. I would have to read more about "output_iterator" to
>> understand whether Boost.Iterator is correct here. With my current
>> understanding of "output_iterator", I would say it's a bug in
>> "boost/iterator/detail/facade_iterator_category.hpp".
>>
>> Perhaps somebody with more knowledge about "output_iterator" and
>> Boost.Iterator can explain to me why an iterator using the
>> "boost::random_access_traversal_tag" for the "CategoryOrTraversal"
>> template parameter of "iterator_facade" will never get the category
>> "output_iterator" (or "input_output_iterator_tag").
>
> Of course I could go on and read more about "output_iterator", or find out whether the Boost.Iterator documentation has to say something about this issue, but since I only came to this problem because I wanted to help Jesse Perla on a problem with boost::multi_array, I would much prefer if an "iterator expert" could "take over".
>
> Regards,
> Thomas
Without being an expert, a quick review of
http://www.boost.org/doc/libs/1_42_0/libs/iterator/doc/iterator_facade.html#iterator-category
shows that std::output_iterator_tag is never chosen as the iterator
category by boost::iterator_facade. It also shows that the behavior of
choosing std::input_iterator_tag for your particular case is the
documented behavior. Of course, this doesn't shed any light on the
motivation behind this decision. It may have been the intention that
output iterators should be explicitly declared as such by specifying the
category as std::output_iterator_tag.
This aspect of the standard that treats iterators with proxy references
as automatically have the very lowest of traversal categories is
annoying at best. I've resorted to overriding the traversal category
normally deduced by boost::iterator_facade; I haven't had any ill
effects yet, but I'm not sure *technically* what parts of the standard
(and *practically*, in terms of the various implementations on the
various compilers) depends on, e.g., dereferenced random-access
iterators returning lvalue references.
- Jeff