iterator_facade, decoupling of access and traversal?
After having read http://www.boost.org/doc/libs/1_35_0/libs/iterator/doc/index.html I have been left, believing that the new iterator concepts will allow me to create an iterator that may return a proxy instead of a reference. I tried to do this by using the iterator_facade template, and for the "Reference" parameter I specified a proxy class that has a conversion operator to the "Value" type. This almost works, but fails for expressions of Val v = it[n]; expressions, because iterator facade does not return "Reference" objects in that case, but operator_brackets_proxy objects that are convertible to "Reference". So I am wondering if I understand something wrong? Isn't the decoupling of access and traversal meant to allow "Reference" be a proxy object? Any hints appreciated! -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at
Roland Schwarz schrieb:
So I am wondering if I understand something wrong? Isn't the decoupling of access and traversal meant to allow "Reference" be a proxy object?
On page http://www.boost.org/doc/libs/1_35_0/libs/iterator/doc/new-iter-concepts.htm... I read:
A difficult design decision concerned the operator[]. ... operator[] is only required to return something convertible to the value_type (for a Readable Iterator), and is required to support assignment i[n] = t (for a Writable Iterator).
So I believe my intended interator is categorized as Readable, Writeable, Random access traversal However operator[] returns something that is convertible to "reference" and not to value_type (as I expected). Can this behaviour of iterator_facade be controlled somehow? -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at
Roland Schwarz wrote:
However operator[] returns something that is convertible to "reference" and not to value_type (as I expected). Can this behaviour of iterator_facade be controlled somehow?
The attached patch to iterator_facade made my "Readable" and "Writeable" == "Swapable" iterator work. However I am not practised enough to tell if this will break something else. At least it makes the bracket_proxy return something that is convertible to value_type and not only to reference. -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at
Roland Schwarz wrote:
The attached patch to iterator_facade made my "Readable" and "Writeable" == "Swapable" iterator work. However I am not practised enough to tell if this will break something else.
I believe this would break code where reference == value_type (not unusual for input iterators), because the two conversion operators would have the same target type. This could be solved with specialization. It might also introduce ambiguities where reference == value_type& (requirement for lvalue iterators). This should be pretty trivial to test. void foo(const int &i); int main() { iterator_with_value_type_ref_as_reference r = get_that_iterator(); foo(r[0]); } It should also be possible to solve via specialization - there's no need for the conversion to value_type if reference == value_type&. Sebastian
Sebastian Redl wrote:
I believe this would break code where reference == value_type (not unusual for input iterators), because the two conversion operators would have the same target type.
Hmm, yes. Why would we need the conversion to reference from a proxy anyways? Shouldn't this be just to value_type? (As the docs let me believe.)
It might also introduce ambiguities where reference == value_type& (requirement for lvalue iterators). This should be pretty trivial to test.
There shouldn't be a proxy for reference == value_type& anyways, should it? What I do not understand yet is why the iterator_facade attempts to return a proxy at all. Shouldn't this be in complete control of the user of the library? I.e. the user has to implement the correct access mode by providing proper classes for value_type and reference. And if she decides to have swapable (no lvalue) iterator just a suitable class for reference (which can be a proxy) has to be provided. Perhaps I am overlooking something important here, but I think the bracket proxy is superfluous in iterator_facade. -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at
I filed a ticket about the issue: http://svn.boost.org/trac/boost/ticket/1947 -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at
on Sat May 24 2008, Roland Schwarz <roland.schwarz-AT-chello.at> wrote:
Roland Schwarz wrote:
However operator[] returns something that is convertible to "reference" and not to value_type (as I expected). Can this behaviour of iterator_facade be controlled somehow?
The attached patch to iterator_facade made my "Readable" and "Writeable" == "Swapable" iterator work. However I am not practised enough to tell if this will break something else.
At least it makes the bracket_proxy return something that is convertible to value_type and not only to reference.
That looks like a correct fix to me. I plan to spend a little time on the iterator library soon, and would be very happy to apply this (or something very like it). Would you mind submitting your patch in a ticket at http://svn.boost.org? Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Could you consider the possibility of adding templated constructors to the iterator library?. I liked the iterator library in made a key part of the implemenation of the serialization library. It was perfect from my standpoint in that it permited me to make smaller iterators and compose them at compile time except for one thing.... The syntax for composing interators wasn't transparent enough for me. I fixed this by adding (through derivation) templated constructors. This let me compose iterators with much simpler syntax. It also permitted me to make "iterator snippets" which composed from other "iterator snippets" (via typedef). Which permited me to express what I wanted in a transparent way. (ok a lot of < and > characters - but still I like it). And all built a compile time so in theory anyway - could be compiled down to optimally efficient code. I called this approach "dataflow iterators" as that what it seemed like to me. Its described in the serialization library. I was always disappointed that no one seemed to find it as appealing as I did - but of course tastes differ. Another thing that would be useful would be the notion of "polymorphic iterators". A case study/example/test where by a family of iterators with the same iterface are derived from base class and the public operations are implemented as virtual functions. This would permit plugging in / composing different iterators at run time. In the serialization library, the concept of polymorphic archives fulfills the same purpose. It was achived without touching the "base library" but by making a "bridge" structure (like microsoft COM) which attached a separate "polymophic" interface via multiple inheritance. my 2 cents. David Abrahams wrote:
That looks like a correct fix to me. I plan to spend a little time on the iterator library soon, and would be very happy to apply this (or something very like it). Would you mind submitting your patch in a ticket at http://svn.boost.org?
Thanks,
Robert Ramey wrote:
I was always disappointed that no one seemed to find it as appealing as I did - but of course tastes differ.
You never asked. I liked them. -- Sohail Somani http://uint32t.blogspot.com
on Sun May 25 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Could you consider the possibility of adding templated constructors to the iterator library?.
Yes; could you open a ticket in Trac with all the pertinent info? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Sun May 25 2008, David Abrahams <dave-AT-boostpro.com> wrote:
on Sun May 25 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Could you consider the possibility of adding templated constructors to the iterator library?.
Yes; could you open a ticket in Trac with all the pertinent info?
ping? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (5)
-
David Abrahams -
Robert Ramey -
Roland Schwarz -
Sebastian Redl -
Sohail Somani