dereferencing cursors
Hello,
I've been reading "The Cursor/Property Map Abstraction"
Doc.No: N1873=05-0133 by Dietmar Kühl and David Abrahams.
I like the idea of cursors, they're so much simpler than C++
iterators, but I am concerned regarding dereferencing a cursor.
Here's the relevant paragraph...
"The presence of a dereference operator on cursors might seem strange,
since since the goal is to separate access from traversal. For instance,
the values of a property map could be read as pm(c) instead of pm(*c).
It turns out that the dereference operation is required in order to
reasonably support traversal adapters. If you have a property map that
accepts foo_cursor arguments, it may not be designed to accept a
reverse_cursor
Louis Lavery
Hello,
I've been reading "The Cursor/Property Map Abstraction" Doc.No: N1873=05-0133 by Dietmar Kühl and David Abrahams.
I like the idea of cursors, they're so much simpler than C++ iterators, but I am concerned regarding dereferencing a cursor. Here's the relevant paragraph...
"The presence of a dereference operator on cursors might seem strange, since since the goal is to separate access from traversal. For instance, the values of a property map could be read as pm(c) instead of pm(*c). It turns out that the dereference operation is required in order to reasonably support traversal adapters. If you have a property map that accepts foo_cursor arguments, it may not be designed to accept a reverse_cursor
directly. Like so many others, this problem is solved by adding a level of indirection: dereferencing a cursor yields an intermediate key, and the key type of a traversal adapter is the same as that of its underlying iterator." ...and my concern is that if all cursors yield the same key type then this could lead to hard to find bugs.
Nobody said that all cursors yield the same key type.
EG. Suppose we have a property map (pm) of Ts and that it's useful to reverse it but that reversing it requires reversing the Ts[1], not just applying a reverse cursor.
That's a different transformation from reverse, which involves not only a traversal (cursor) adapter, but also an access (property map) adapter.
I guess we'd wrap pm in a reversed property map (rpm)
Sure.
that supplies its own cursors (rc),
?? Property maps don't supply cursors.
some thing like...
t = pm(*c); // forward access t = rpm(*rc); // reversed access - returns reversed t
...but, of course, there's nothing to stop...
t = pm(*rc); t = rpm(*c);
There is something to stop it if you design it that way.
But may be there are other advantages that outweight this drawback?
The ability to adapt traversal independently from access outweighs it.
I'd be interested to know. Also, has there been any further work on the proposal?
Not much.
Thanks, Louis.
[1] EG. Reversing a 2D curve made from arcs of circles could well require reversing the direction of the returned arcs.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (2)
-
David Abrahams
-
Louis Lavery