On Thu, 6 Nov 2014 22:02:28 -0500 Matei David wrote:
I have some questions about the Boost Iterator library.
I've recently discovered the "hard way", meaning through impenetrable TMP error messages :), that when using boost::iterator_adaptor, the derived iterator type does not (always??) inherit the pointer typedef of the base iterator type. I mean, the iterator_adaptor glue class does not have this typedef.
So, for example, I have a Base_Iterator type with: Base_Iterator::pointer != Base_Iterator::value_type*
If I do: class Derived_Iterator : public boost::iterator_adaptor< Derived_Iterator, Base_Iterator > {...}
then, strangely I find: Derived_Iterator::value_type == Base_Iterator::value_type (OK) Derived_Iterator::pointer == Base_Iterator::value_type* != Base_Iterator::pointer (not OK)
I looked at the documentation, and I did find a mention of this, but only for iterator_facade, here: http://www.boost.org/doc/libs/develop/libs/iterator/doc/iterator_facade.html
The corresponding page for iterator_adaptor does not mention the pointer typedef at all. While for facade using a plain pointer seems ok (no other reasonable default), I would argue that for adaptor this is not ok. Is this expected behaviour or a bug?
Within the same setting, and in what could be a related issue, I also found that the intermediate boost::iterator_adaptor<> class does not seem to contain the default/common sense definition: Base_Iterator operator->() const { return this->base(); }
I didn't look inside the source code of boost::iterator_adaptor, but I found a situation where I have to put this definition explicitly inside Derived_Iterator for my code to compile (without it, it doesn't). Does this sound like expected behaviour?
Some clarifications... I used some words like "inherit" and
"missing" in the wrong way.
There are 3 classes involved here:
- Derived_Iterator: my class
- iterator_adaptor