Re: [boost] [iterator][range] BoostIteratorTraversalConcepts-aware boost::advance/distance

Subject: Re: [boost] [iterator][range] BoostIteratorTraversalConcepts-aware boost::advance/distance
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2017-07-04 09:47:34

On 04/07/2017 10:26, Andrzej Krzemienski via Boost wrote:

> Not necessarily non-conforming. I guess one could come up with such
> interpretation, but the Standatd is not really explicit about this. The
> most relevant sentence, "`iterator_category` shall be defined to be the
> most specific category tag that describes the iterator’s behavior" -- it
> could be read as "do not use any tag but these five" or "if you define a
> tag for RandomAccessIterator don't defien iterator_category as
> forward_iterator_tag".

My interpretation is that it must be one of the standard types:

"the library introduces category tag classes which are used as compile 
time tags for algorithm selection. They are: input_iterator_tag, 
output_iterator_tag, forward_iterator_tag, bidirectional_iterator_tag 
and random_access_iterator_tag. 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."

"the most specific category" refers to standard tags. The standard can't 
speak about "most specific" types that it does not know. BIterator types 
tags are not "more specific", they just mean something different.

The inheritance relationship is guaranteed between standard types but an 
implementation is free to assume there are no additional tags. It's not 
a customization point.

> Also, the GCC problem is not caused by iterator tags deriving from the
> standard tags, but because std::prev is instantiated with an InputIterator.

Right. This (IMHO clear) non-conformance from Boost.Iterator was derived 
from an unrelated problem. I don't know why Boost.Iterator needs to 
define iterator_category to something non-standard, as they could have 
defined the iterator_category to an standard one and use another typedef 
for traversal/access attributes.

I mention this issue because in Boost.Container/Intrusive I have been 
bitten by this issue while dispatching iterators, it's been already 
solved, but I considered appropriate to to mention it in this thread.

Sorry for the off-topic-ness,

Best,

Ion