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